SecurityModuleAdminTool
|
Size: 4545
Comment:
|
Size: 6034
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| * '''Launchpad Entry''': UbuntuSpec:SecurityModuleAdminTool | * '''Launchpad Entry''': UbuntuSpec:SecurityModuleAdminTool |
| Line 7: | Line 7: |
| This specification defines an administration tool used to setup and apply security profiles to programs. |
This specification defines administration tools used to setup and apply security profiles to programs and manage security frameworks. |
| Line 11: | Line 11: |
| The main security frameworks (["SELinux"] and AppArmor) are in Ubuntu repositories. However, their setup and management are not easy and relies mainly on command |
The main security frameworks (["SELinux"] and AppArmor) are in Ubuntu repositories. However, their setup and management are not easy and relies mainly on command |
| Line 16: | Line 16: |
| ["SELinux"] is already in the kernel and the utilities are in main. There are a number of profiles installed by default. |
["SELinux"] is already in the kernel and the utilities are in universe. There are a number of profiles installed by default. Profiles have been tested in Debian and RHEL/Fedora. |
| Line 20: | Line 21: |
| are a number of profiles installed by default. | are a number of profiles installed by default. Profiles have been tested in Novell/SELS. |
| Line 23: | Line 25: |
| * Alice has installed an ubuntu server to provide file and printer sharing | * Alice has installed an ubuntu server to provide file and printer sharing |
| Line 34: | Line 36: |
| This specification focuses on a high level management of security policies. | |
| Line 35: | Line 38: |
| services. It should be possible to update the profile according to the audit logs. |
services. It should be possible to update the profile according to the audit logs. Policy edition is out of the scope of this specification. It requires a great knowledge of the security frameworks and the syntax of their respective configuration files. |
| Line 40: | Line 46: |
| * Provide good profiles In order to create a good profile, the target program has to be well tested. |
=== Good profiles === In order to create a good profile, the target program has to be well tested. |
| Line 43: | Line 49: |
| updates : for each update, the profile has to be checked and potentialy | updates : for each update, the profile has to be checked and potentialy |
| Line 46: | Line 52: |
| Test suite exists. They can be used to generated policies. | Test suite exists. They can be used to generated policies and make sure that policies are up-to-date. |
| Line 48: | Line 55: |
| * Frontend administration tool The frontend is used by the end user to enable profiles for program. The frontend should be framework agnostic. |
=== Administration tools === Functionalities : * Enable/Disable security framework. * Enable/Disable on per service basis : security profiles can be applied to individual service. * Notify user of policy violation via : * daily log report sent to the system administrator * on the console * an applet in the taskbar * in the security profile administration tool * via a monitoring framework (eg nagios). * Sumarize how many policy violations have been reported for each service. * Update the local profile according to the generated audit log. * Report to policy maintainers : send the audit trace to the policy maintainers. They can check whether the violation is local to the system or a problem with the default packaged policy. Automatically file a bug under apparmor, instead of the application. The administration tools should be security framework agnostic. |
| Line 62: | Line 87: |
| * dovecot, fetchmail | |
| Line 64: | Line 90: |
| * in the application package. Requires to educated package maintainer about security policy framework. |
* in the application package. Requires to educate package maintainers about security policy frameworks. |
| Line 69: | Line 95: |
| It may be interesting to provide such a hardlinking in an LTS release. | |
| Line 70: | Line 97: |
| Feedback from users should be leveraged to improve shipped profiles. Integration with [Apport]. |
Feedback from users should be leveraged to improve packaged profiles. Integration with [Apport], logcheck. |
| Line 74: | Line 101: |
| It is based on the services-admin tool. | |
| Line 76: | Line 102: |
| * Reporting extension : It can be extended with a basic reporting function showing how many policy violation have been reported. A function to report the violation in order to improve the policy. Automatically file a bug under apparmor, instead of the application. * Profile update : The end user can be offered the choice to update the profile according to the generated audit log. * Realtime notification : Policy violation can be monitored and reported via email. |
Different user interface should be provided : * command line script (for advanced system administrator) * ncurse interface (for servers without X installed) * GUI interface (for non-technical and junior system administrator) |
| Line 99: | Line 117: |
| AppArmor requires a manual compilation of the kernel module. The solution is to include AppArmor in the kernel. |
AppArmor requires a manual compilation of the kernel module. The solution is to include AppArmor in the kernel. |
| Line 103: | Line 121: |
| from init script. Unload/load modules. | |
| Line 106: | Line 125: |
| move to/from directory /etc/apparmor.d. | |
| Line 112: | Line 132: |
| ["SELinux"] has to be activated on the kernel command line, at the | ["SELinux"] has to be activated on the kernel command line, at the |
| Line 116: | Line 136: |
| Activation of a new profile : load/unload modules in the kernel. |
|
| Line 117: | Line 139: |
| Activation of a new profile : |
Frameworks can be in three different states : * enforcing * learning * disabled |
| Line 121: | Line 145: |
| * AppArmor : AppArmor is not included in the kernel by default and requires the compilation of a module. |
* AppArmor : AppArmor is not included in the kernel by default and requires the compilation of a module. |
| Line 125: | Line 149: |
| Utilities can be moved into main. * SELinux : Utilities can be moved into main. |
|
| Line 128: | Line 156: |
| SELinux and AppArmor profile integration/conversion tool. Break down the spec. Testing that profile works by replacing the binary with another one and making sure that policy violation are reported. |
Launchpad Entry: SecurityModuleAdminTool
Created: 2007-05-09 by MathiasGug
Packages affected: apparmor-profiles, selinux-policy
See also: AppArmor, ["SELinux"]
Summary
This specification defines administration tools used to setup and apply security profiles to programs and manage security frameworks.
Rationale
The main security frameworks (["SELinux"] and AppArmor) are in Ubuntu repositories. However, their setup and management are not easy and relies mainly on command line tools.
["SELinux"] is already in the kernel and the utilities are in universe. There are a number of profiles installed by default. Profiles have been tested in Debian and RHEL/Fedora.
AppArmor is not included in the kernel. All the packages are in universe. There are a number of profiles installed by default. Profiles have been tested in Novell/SELS.
Use Cases
- Alice has installed an ubuntu server to provide file and printer sharing service via samba. She wants to increase the security level of her server.
She opens the security policy manager and applies an AppArmor security policy to the samba service.
- Bob has just installed a LAMP server using the ubuntu alternate cd. He wants to increase the security of his server by using ["SELinux"]. He opens the security policy manager and applies a ["SELinux"] security policy to the LAMP service.
Scope
This specification focuses on a high level management of security policies. It should be made easy to activate and deactivate security profiles for services. It should be possible to update the profile according to the audit logs.
Policy edition is out of the scope of this specification. It requires a great knowledge of the security frameworks and the syntax of their respective configuration files.
Design
Good profiles
- In order to create a good profile, the target program has to be well tested. That leads to automatic software testing. This is also important for software updates : for each update, the profile has to be checked and potentialy updated if the behaviour of the software has changed. Test suite exists. They can be used to generated policies and make sure that policies are up-to-date.
Administration tools
- Functionalities :
- Enable/Disable security framework.
- Enable/Disable on per service basis : security profiles can be applied to
- individual service.
- Notify user of policy violation via :
- daily log report sent to the system administrator
- on the console
- an applet in the taskbar
- in the security profile administration tool
- via a monitoring framework (eg nagios).
- Sumarize how many policy violations have been reported for each service.
- Update the local profile according to the generated audit log.
- Report to policy maintainers : send the audit trace to the policy
- maintainers. They can check whether the violation is local to the system or a problem with the default packaged policy. Automatically file a bug under apparmor, instead of the application. The administration tools should be security framework agnostic.
Implementation
Good profiles
The base profiles can be used as a start. Profiles for the following services can be provided :
- ntpd
- named
- samba (smbd, nmbd)
- postfix
- apache from the standard LAMP installation
- dovecot, fetchmail
Where profiles should be included ?
- in the application package. Requires to educate package maintainers about security policy frameworks.
- in one package policy. The policy maintainer has to track all application changes.
- one package policy for each application. May lead to lots of small packages. It may be interesting to provide such a hardlinking in an LTS release.
Feedback from users should be leveraged to improve packaged profiles. Integration with [Apport], logcheck.
Administration tool
Different user interface should be provided :
- command line script (for advanced system administrator)
- ncurse interface (for servers without X installed)
- GUI interface (for non-technical and junior system administrator)
Ressources :
Yast2 provides an administration tool for AppArmor.
- Fedora and RHEL 5 have an administration tool for ["SELinux"] :
- system-config-selinux
[https://hosted.fedoraproject.org/projects/setroubleshoot Setroubleshoot] :
A User Friendly Tool for Notification & Diagnosis of AVC Denials
Security module backends
AppArmor requires a manual compilation of the kernel module. The solution is to include AppArmor in the kernel.
Enable/disable apparmor :
- from init script. Unload/load modules.
Activation of a new profile : restart apparmor :
- move to/from directory /etc/apparmor.d. /etc/init.d/apparmor restart
[http://outflux.net/blog/archives/2007/04/02/apparmor-now-in-feisty/ AppArmor now in feisty]
- ["SELinux"]
Enable/disable selinux : ["SELinux"] has to be activated on the kernel command line, at the bootloader level. Enabling/disabling it requires rebooting the system.
Activation of a new profile :
- load/unload modules in the kernel.
Frameworks can be in three different states :
- enforcing
- learning
- disabled
Outstanding Issues
the compilation of a module. AppArmor has been posted on the lklm for inclusion in April 2007. Response has been much better compared to the previous request. Utilities can be moved into main.
- SELinux :
Utilities can be moved into main.
BoF agenda and discussion
SELinux and AppArmor profile integration/conversion tool.
Break down the spec.
Testing that profile works by replacing the binary with another one and making sure that policy violation are reported.
SecurityModuleAdminTool (last edited 2008-08-06 16:28:34 by localhost)