SecurityModuleAdminTool

Differences between revisions 1 and 8 (spanning 7 versions)
Revision 1 as of 2007-05-09 21:58:55
Size: 3406
Editor: 3
Comment:
Revision 8 as of 2007-05-28 15:30:27
Size: 7746
Editor: dsl-148-36
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
 * '''Launchpad Entry''': UbuntuSpec:SecurityModuleAdminTool  * '''Launchpad Entry''': UbuntuSpec:security-module-admin-tool
 * '''Created''': 2007-05-09 by MathiasGug
Line 3: Line 4:
 * '''See also''': AppArmor, SELinux  * '''See also''': AppArmor, ["SELinux"]
Line 6: 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 10: Line 11:
The main security frameworks (SELinux and AppArmor) are in Ubuntu repositories. The main security frameworks (["SELinux"] and AppArmor) are in Ubuntu
repositories.
Line 14: 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 18: 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 27: Line 31:
 to increase the security of his server by using SELinux.
 He opens the security policy manager and applies a SELinux security policy to
 to increase the security of his server by using ["SELinux"].
 He opens the security policy manager and applies a ["SELinux"] security policy to
Line 32: Line 36:
This specification focuses on a high level management of security policies.
Line 33: 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 38: Line 46:
 * Provide good profiles === Good profiles ===
Line 41: Line 49:
   updates : for each update, the profile has to be checked and potentialy
   updated if the behaviour of the software has changed.

 * Frontend administration tool
   The frontend is used by the end user to enable profiles for program. The
   frontend should be framework agnostic.
   updates : for each update, the profile has to be checked and potentially
   updated if the behavior 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.
 * Show security framework status :
   * list loaded security profiles and their mode.
   * list services that are protected by a profile and their mode.
   * list services that have a profile defined but which is not applied.
   * summarize how many policy violations have been reported for each service.
 * Enable/Disable on per service basis : security profiles can be applied to
   individual service.
 * Notify user of policy violation via :
   * email
   * 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).
 * 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.

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 51: Line 89:
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

==== List of profiles ====
The base profiles shipped with upstream AppArmor can be used as a starting point.
As a first step, profiles for all network services in main should be provided.
 * Profile enabled by default in /etc/apparmor.d/ :
    * klogd, syslogd
    * named
    * ntpd
    * syslog-ng (in universe)
    * identd (in universe)
    * nscd (in universe)
 * Profile disabled by default, but packaged in /usr/share/doc/apparmor-profiles/extras :
    * apache2 : this profile should be updated to protect the standard LAMP installation from Ubuntu server.
    * portmap
    * procmail
    * rpc.lockd, rpc.statd
    * svnserve
    * slapd
    * postfix
    * mysqld
    * nmbd, smbd
    * squid
    * sshd
    * vsftpd
    * xinetd
    * dhcpcd (in universe)
    * freshclam (in universe)
    * mlmmj (in universe)
    * spamc, spamd (in universe)
    * dhcpd (in universe)
    * imapd (in universe)
    * ftpd (in universe)
    * ipop2d, ipop3d (in universe)
    * lighttpd (in universe)
    * oidentd (in universe)
    * sendmail (in universe)
 * Network services in main for which profiles don't exist :
   * dovecot

==== 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.

==== Profile testing ====
In order to improve the quality of profiles, feedback from users should be leveraged.
 * AppArmor :
   * provide apparmor utilities and kernel modules also for feisty (see [https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/116627 LP#116627 latest apparmor utilities for feisty]).

Integration with [Apport], logcheck.
Line 60: Line 144:
It is based on the services-admin tool.

 * Reporting extension :
   It can be extended with a basic reporting function showing how many policy
   violation have been reported.

 * Profile update :
   The end user can be offered the choice to update the profile according to the
   generated audit log.

Yast2 provides an administration tool for AppArmor and Fedora has an
administration tool for SELinux.

==== Command line scripts ====

==== Console based interface ====

==== GUI interface ====

==== Ressources ====
 * Yast2 provides an administration tool for AppArmor.
 * apparmor-utils has some perl scripts.
 * 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
Line 79: Line 164:
Enable/disable apparmor :
 from init script. Unload/load modules.
Line 81: Line 169:
 move to/from directory /etc/apparmor.d.
Line 83: Line 172:
There are some basic command line scripts in apparmor-utils. They are shipped by upstream and written in perl.

Line 85: Line 177:
 * SELinux
SELinux has to be activated on the kernel command line, at the bootloader level.
UsingAppArmor

* ["SELinux"]
Enable/disable selinux :
["
SELinux"] has to be activated on the kernel command line, at the
bootloader level.
Line 90: Line 186:
 load/unload modules in the kernel.

Frameworks can be in three different states :
 * enforcing
 * learning
 * disabled
Line 95: Line 196:
AppArmor has been posted on the lklm for inclusion in April 2007. 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.
Line 98: Line 204:

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.

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 potentially updated if the behavior 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.
  • Show security framework status :
    • list loaded security profiles and their mode.
    • list services that are protected by a profile and their mode.
    • list services that have a profile defined but which is not applied.
    • summarize how many policy violations have been reported for each service.
  • Enable/Disable on per service basis : security profiles can be applied to
    • individual service.
  • Notify user of policy violation via :
    • email
    • 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).
  • 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.

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)

Implementation

Good profiles

List of profiles

The base profiles shipped with upstream AppArmor can be used as a starting point. As a first step, profiles for all network services in main should be provided.

  • Profile enabled by default in /etc/apparmor.d/ :
    • klogd, syslogd
    • named
    • ntpd
    • syslog-ng (in universe)
    • identd (in universe)
    • nscd (in universe)
  • Profile disabled by default, but packaged in /usr/share/doc/apparmor-profiles/extras :
    • apache2 : this profile should be updated to protect the standard LAMP installation from Ubuntu server.
    • portmap
    • procmail
    • rpc.lockd, rpc.statd
    • svnserve
    • slapd
    • postfix
    • mysqld
    • nmbd, smbd
    • squid
    • sshd
    • vsftpd
    • xinetd
    • dhcpcd (in universe)
    • freshclam (in universe)
    • mlmmj (in universe)
    • spamc, spamd (in universe)
    • dhcpd (in universe)
    • imapd (in universe)
    • ftpd (in universe)
    • ipop2d, ipop3d (in universe)
    • lighttpd (in universe)
    • oidentd (in universe)
    • sendmail (in universe)
  • Network services in main for which profiles don't exist :
    • dovecot

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.

Profile testing

In order to improve the quality of profiles, feedback from users should be leveraged.

Integration with [Apport], logcheck.

Administration tool

Command line scripts

Console based interface

GUI interface

Ressources

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

There are some basic command line scripts in apparmor-utils. They are shipped by upstream and written in perl.

[http://outflux.net/blog/archives/2007/04/02/apparmor-now-in-feisty/ AppArmor now in feisty]

UsingAppArmor

  • ["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.


CategorySpec

SecurityModuleAdminTool (last edited 2008-08-06 16:28:34 by localhost)