This specification defines administration tools used to setup and apply security profiles to programs and manage security frameworks.


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.


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.


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)


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.

Event auditing

Both AppArmor and SELinux use the audit sub-system of the kernel to log information. If the audit daemon is running, it will dump all the events into /var/log/audit/audit.log. If not, audit messages are handled by syslog and sent to /var/log/messages by default.

AppArmor provided a daemon (aa-eventd in utils) that scans log files and dumps audit messages into an sqlite database for further processing by reporting tools. The main reason for doing this is speed.

Reporting tools

AppArmor provides a perl module that can generate reports using the sqlite database. The module is used by Yast.

The audit package provides tools (ausearch, aureport) to extract information from the audit logs. SELinux is supported. AppArmor support is very basic.

Administration tool

Command line scripts

Console based interface

GUI interface


  • 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
    • 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

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

AppArmor now in feisty


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)