We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

secPaver: Security Policy Development Tool

00:00

Formal Metadata

Title
secPaver: Security Policy Development Tool
Title of Series
Number of Parts
287
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Security design is an very important step in the software development. In order to meet the principle of least privilege, developers make rules for applications based on data flow and control flow of processes, such as SELinux and AppArmor. This step can be automated with secPaver. With the permission description of application, secPaver can generate security policy for different security mechanisms. By this way, security design can be simplified, and developers do not need to know many details about security mechanisms. secPaver is a policy development tool that supports multiple security mechanisms. It aims to help users implement end-to-end security policy development, including visible policy design, iterative development, and policy release. It provides functions such as policy configuration, automatic generation, running test, missing rule gathering, and policy package export. secPaver shields security mechanism details and abstracts unified policy configuration file definitions and operation interfaces for different security mechanisms, improving policy development efficiency and reducing learning costs for developers.
Engineering drawing
Open sourceInformation securityPhysical systemComputer fileComputer networkInterprozesskommunikationGamma functionUser profileNormed vector spaceElement (mathematics)System administratorSoftware developerSoftwareTask (computing)WorkloadIdeal (ethics)Process (computing)Modul <Datentyp>Repository (publishing)Information securityDependent and independent variablesDefault (computer science)Cartesian coordinate systemFirewall (computing)WritingPhysical systemSystems analysisData integritySystem callProcess (computing)SoftwareRule of inferenceInterprozesskommunikationProper mapDistribution (mathematics)Group actionFunctional (mathematics)Kernel (computing)Sound effectOpen sourceSet (mathematics)Software frameworkMereologyModule (mathematics)Software developerComputer fileAsynchronous Transfer ModeCodeType theoryGame controllerMultiplicationSystem administratorTask (computing)Flow separationWordDigitizingWorkloadElectronic mailing listContext awarenessProjective planeObject (grammar)Different (Kate Ryan album)Address spaceFunction (mathematics)Musical ensembleRow (database)Predicate (grammar)Term (mathematics)Forcing (mathematics)Power (physics)Endliche ModelltheorieMathematicsECosComputer programmingService (economics)CASE <Informatik>Inheritance (object-oriented programming)Right angleComputer configurationForestRevision controlQuicksortData storage deviceTrailSoftware testingAxiom of choiceOrder (biology)Multiplication signOpen setShared memoryCue sportsMetropolitan area networkConditional-access moduleSpacetimeLevel (video gaming)Natural languageMedical imagingPosition operatorComputer animation
Asynchronous Transfer ModeInformation securitySoftware developerBlogMilitary operationInterface (computing)Installation artFile formatMassModul <Datentyp>Internet service providerScripting languageServer (computing)ArchitectureClient (computing)Type theoryPhysical systemMathematical analysisCompilerProcess (computing)Plug-in (computing)Demo (music)InformationBuildingElectronic mailing listTemplate (C++)Touch typingPhase transitionModule (mathematics)Configuration spaceProcess (computing)Rule of inferenceSampling (statistics)Set (mathematics)SoftwareClient (computing)Computer programmingSource codePosition operatorOcean currentForcing (mathematics)Roundness (object)Core dumpAdditionFlow separationMatching (graph theory)Thermal radiationSoftware testingDifferent (Kate Ryan album)Message passingSurgeryFunctional (mathematics)Software developerComputer virusInformation securityBasis <Mathematik>Multiplication signData storage deviceArithmetic progressionMaterialization (paranormal)Extension (kinesiology)NeuroinformatikComplete metric spaceForestAuditory maskingData managementParity (mathematics)Real numberComputer fileComputer architectureAsynchronous Transfer ModeMusical ensembleStudent's t-testElectric generatorMereologyContent (media)Focus (optics)Sign (mathematics)System callProjective planeComputer clusterCryptographyTemplate (C++)Touch typingVirtual machineCartesian coordinate systemInheritance (object-oriented programming)Insertion lossFormal languageCASE <Informatik>Operator (mathematics)Shared memoryDistribution (mathematics)Configuration spaceDefault (computer science)Plug-in (computing)Physical systemDemosceneElectronic mailing listServer (computing)Cycle (graph theory)Error messageFile formatType theoryDemonService (economics)Parameter (computer programming)Integrated development environmentSound effectRow (database)LoginMathematical optimizationEntire functionCodeDirection (geometry)Interface (computing)Scripting languageResultantStructural loadXMLComputer animation
Demo (music)Configuration spaceUDP <Protokoll>Installation artData typeGroup actionCommunications protocolConnected spaceInformationBuildingModule (mathematics)Demo (music)Configuration spaceComputer fileTemplate (C++)Message passingProjective planeDemosceneCartesian coordinate systemPlug-in (computing)NumberService (economics)Keyboard shortcutGame controllerNeuroinformatikPredictabilityReplication (computing)Computer programmingStructural loadBuildingModule (mathematics)Electronic mailing listFile formatWritingSound effectLink (knot theory)Installation artServer (computing)Scripting languageIntegrated development environmentReading (process)Virtual machine40 (number)ResultantProcess (computing)Office suiteChaos (cosmogony)Metropolitan area networkCircleRevision controlEndliche ModelltheorieForestTunisStaff (military)Operator (mathematics)StatisticsCovering spaceRoundness (object)Sparse matrixMereologyData conversionComputer iconFlow separationSoftware testingComputer animation
Configuration spaceModul <Datentyp>Installation artDemo (music)Module (mathematics)Term (mathematics)Communications protocolUDP <Protokoll>Scripting languageDemo (music)Computer programmingComputer fileProcess (computing)TrailIntegrated development environmentControl flowService (economics)Sound effectArmComputer clusterRow (database)Moment (mathematics)Message passingTerm (mathematics)State of matterMobile appProjective planeCartesian coordinate systemPhysical systemGame controllerSimilarity (geometry)Computer animation
Configuration spaceDemo (music)UDP <Protokoll>Information securityPlanningPattern languageMetropolitan area networkWave packetMobile appGame controllerAuditory maskingDifferent (Kate Ryan album)Cartesian coordinate systemModule (mathematics)Set (mathematics)Type theoryComputer animation
Graphical user interfaceInternet service providerType theoryFile formatCompact spacePlanningRepository (publishing)Coma BerenicesInformation securityMobile appGraphical user interfaceFile formatCodeProjective planeConfiguration spaceLattice (order)Ocean currentLevel (video gaming)Focus (optics)Electronic mailing listComputer animation
Computer animation
Transcript: English(auto-generated)
Hello everyone, my name is Luha Xin, an OS engineer.
I have been working for two years and my work is mainly about OS security technique, such as access control and integrity protection. Today, I am going to share with you some of our work in SecPaver project, which is a feature in OpenOiler. To begin with, let me start by saying a few words about OpenOiler.
OpenOiler is an open-source Linux OS distribution. It is positioned as a secure, stable and easy-to-use OS and an ecosystem of digital infrastructure. At the same time, OpenOiler is also an innovation community.
It encourages everyone to propose new ideas and solutions, together driving a growing and prosperous application ecosystem. Before getting into the details, the subject of my today talk is about the security policy of applications. The security policy is usually a set of rules that define the permissions of applications,
and tell each process what you can do and cannot do, such as file access, network transfer, and IPC using. The proper policies can effectively improve system security and resilience. With the security policy, applications can run with the least privilege.
Even if they are attacked, they cannot perform actions beyond the rule limits. The support of OS is usually required for security policies to take effect. For example, Linux kernel provides the LSM framework.
Lots of functions are inserted in kernel code for security check, such as system calls. Based on the LSM framework, Linux provides several security modules, such as SNX, APARMA, SMAC, and TOMOYO. Of course, the LSM is not the only way to contract access.
Usually, the security policy is determined and loaded into OS by administrators. Then, the security modules perform access control according to the policies. The syntax and usage vary with the security modules. Here we show three kinds of policy, SNX, APARMA, and TOMOYO.
SNX, originally developed by NSA, is one of the most widely used security modules. In some Linux distributions, like Fedora and CentOS, SNX is enabled by default. SNX uses labels to identify subjects and objects.
Every file, plot, process are all labeled with SNX context label. The SNX process also based on labels, determines each label's access and transition. APARMA is another widely used security module. APARMA is path-based and is very easy to use.
Some Linux distributions, like Debian, OpenSUSE, ship with APARMA. However, APARMA sports less permission types than AC Linux. TOMOYO is also path-based. It can be used for system analysis or system security improvement.
Compared to other security modules, TOMOYO provides a learning mode that can easily generate policies. Although security policies can make the system more secure, in many systems, administrators disable the security modules directly or just use the default policies.
The biggest problem is writing security policy is rarely not an easy task. Security hardening is the responsibility of the administrator. They determine firewall roles or auditor roles. However, it is very difficult for them to write application security policies
because they can't know all behaviors of applications in their systems. But for most security modules, policies are written as whitelists, like AC Linux and APARMA. That means if you ignore even one permission in policies, the process won't even run properly.
On the other hand, for software developers, although they are familiar with applications, lack of experience with security policies is another problem. Moreover, developers don't know what OS distributions their applications will run on.
And maintaining all kinds of policies requires really a huge workload. For these questions, our idea is, at first, security policy can be a part of software. Nowadays, many open-source software has released security policies at the same time,
such as Docker, OpenB switch, and TBM to ABRMD. Then, we think security policy can be automatically generated. Developers only need to provide the process permission list of their applications, without learning much about the syntax and usage of security modules.
So we developed the SecPiver project. SecPiver is an open-source security policy development tool, and we designed it as a framework that supports multiple security modules. We hope this tool can make policy development and deployment easier.
SecPiver now is open-source at open-oil community. The main idea of SecPiver is to provide a middle layer, and convert the permission list into different kinds of security policy. With SecPiver, even if you don't know how to write the security policy or how the security modules work,
you can also develop security policies for your applications. This picture can clearly show the optimization of SecPiver for the development process. For a traditional mode, the software development and the security policy development are separated.
But with SecPiver, security policy development can be integrated into software development. Now, the development team collects the behaviors of the applications, exports the permission list, and generates security policies automatically.
Then, the development, testing, release, and deployment of applications and security policies can be synchronized. Here's how we plan the features of SecPiver. We divide the entire policy development cycle into four phases.
Then we think about what SecPiver can do at each phase. In policy design phase, SecPiver provides a policy configuration file that masks the details of different security policies. Developers can determine the permission list of each process with the configuration file.
Furthermore, the GUI is also being supported to make this step much easier. In policy development phase, the policy can be automatically generated according to the permission list. In policy test phase, SecPiver provides process management interfaces,
including policy querying, installing, and uninstalling. The policy learning mode is also supported to find the missing rows during testing. In policy research phase, SecPiver exports a policy package that contains policy files and deployment programs. In this way, policies can be easily deployed in an environment where SecPiver is not installed.
Then let's talk about the architecture. We choose Golang as the development language, and SecPiver is designed as client-server architecture. The client programs include the command line tool and the GUI tool.
The server program is a CMD service. It manages key resources and implements core functions. SecPiver uses a plugin for function extension. The support of different security modules, such as a Linux and a Palmer, is implemented in each value plugins.
You can load different plugins to generate different types of security policies. At the same time, everyone can develop their own plugin by coding and implementing several interfaces and comparing them into Golang plugins. In addition, to make the generated policy more accurate, SecPiver needs to analyze
the system configuration and the existing policies rather than a simple code generation tool. Next, let me show you how to use SecPiver. Firstly, after SecPiver is installed, you can run the SecPiver server daemon with
systemcontrol.peb command and check the loaded engine plugins with peb-engine-list command. For this example, this result means the S-links and Palmer engine plugins is loaded. Then we begin policy generation. We can create a template project at first, and then we modify the config files in project to add the permission list of applications.
The format of project is declared in the SecPiver document. Here's just a simple case. We add the permission set allows the touch command to create the regular file tmp-test.
After that, the policy can be generated by the peb-project-build command and the engine parameter can be used to specify the policy type. For example, S-links or Palmer. After the policy is successfully built, we can run the peb-policy-list command to check the generated policy.
After policy building, we need to check whether the policy meets all our requirements. We use the peb-policy-install command to install the policy. Then we test the touch command and find that the tmp-test file can be created, but the opt-test file cannot be created.
The error message is permission denied, which means the policy has taken effect. After testing, we can use the peb-policy-on-install command to remove this policy. However, the question is, even developers may not be able to list the full permissions of an application.
So the policy learning feature can help a lot. For example, let's assume that the touch command should create the opt-test file, but we just forgot to add this permission.
Then we start policy learning with peb-policy-learn command and run touch command test to create the opt-test file. Then, the second-favor daemon will monitor the audit log and automatically store the missing rows. After testing, the missing rows can be exported, and the missing rows can be added to the project directly.
So the policy can be easily completed. After policy testing, we confirm that the generated policy is OK. Then we can use seccfavor to export a policy package for policy release. In addition to the policy files, the package also contains some script programs for policy, installing, uninstalling, and other operations.
Now, let's see an example that uses seccfavor to develop the scenes and parameter policies for an application.
Now I will show how to develop a scenes policy with seccfavor. This is an open-order OS distribution, and the scenes is enabled by default. I have prepared an application named demo. The demo program will read the computer file, read and write data file, send and receive messages through TTP and UDP.
The data file path and support used for TTP and UDP can be saved in the config file. I have written the seccfavor project for this application. The project template can be auto-generated, and in the project, the resource file and the permission file should be written.
In the resource file, I declare all the files and the file type used by this application. In the permission file, I configure the permission list, including read permission for config file, create, read, write permission for data file, and permission for TTP and UDP.
The permission of netbind service capability is also needed because it should bind support number 80. In this system, I have installed seccfavor with the scenes engine plugin.
Then I use the project build command to generate the scenes policy according to this project. After generating, we can check the policy by policy list command, and we can see the policy has been generated and the status is disabled.
Then I install the policy by policy install command. For scenes policy, the installing has two steps. Firstly, install the generated policy module to the global policy, and load the global policy to kernel.
Secondly, all the file labels should be set correctly. We can check the scenes label of the prediction file, and it has been changed, and the policy module has also been inserted with the scene module.
After that, we can check the policy status become active. Then we check the effect of this policy. This link is white list mode, so only access in the permission list is allowed to be wrong.
I modify the config file and set a new data file path, and then run the application. You can see the application doesn't have the permission to access a new file. Then I change the ttp port, run the application again, and the application can't listen at the new ttp port, so your message is permission denied.
After testing, we can use the policy install command to install the policy, and the access control of the policy is removed.
The scenes label of the replication file is also recovered.
Finally, we can export our policy package for policy release. The policy package is a zip file, including the policy files and some scripts for deployment. With these scripts, the policy can be deployed in other environments that SQL Server is not installed.
Then I will show the similar process for app armor policy development. This environment is Ubuntu with app armor enabled, and the application's SQL project is all same.
Without any policy, the demo program can run properly with the changed data file path. Then I start to generate the app armor policy.
In this environment, I install SQL Paver with app armor plugin. Then I run the same command to generate the app armor policy, and check the policy is generated so the status is disabled.
Then we install the policy, and we can find the demo policy has been loaded in C system with app armor status command.
We run the application again, so access control takes effect. The demo program can only access tmp demo.data file. However, if I change the setting of ttp port, the application can also run.
That's because app armor cannot control the access of port. So you can see, the main purpose of Paver is to provide a middle layer to mask the difference of security modules. Even if you don't understand how these security modules work, you can still write and use security policy by check Paver.
And in the future, more types of security policy will be supported. OK, that's all. Thank you for watching.
And about the future of SQL Paver, we have planned the following features. Firstly, we hope SQL Paver to be much wider. That means SQL Paver need to support all mainstream security policy type, like S links, app armor, smack, and tomojo.
Secondly, the policy learning feature is coming through. Thirdly, the GUI is our next focus. We think the GUI can make the policy designer simpler and more efficient.
Besides, a simpler policy configuration format is also being designed to replace the current JSON format. And currently, SQL Paver project is still in the early stages. If you have any questions or ideas, you can submit issues or code to this project. We really hope more developers can join SQL project and make it better.
Finally, welcome to OpenOL community. OK, that's all I want to show you. Thanks for your attention.