Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: apparmor-gutsy

• Created: 2007-05-29 by MathiasGug

• Packages affected: apparmor

• See also: SecurityModuleAdminTool, AppArmor

LOOKING FOR PROFILE TESTERS. IF YOU CAN HELP GO TO THE APPARMOR TESTPLAN.

Summary

This specification details what should be done for AppArmor in Gutsy.

Release Note

AppArmor is a security framework.

Rationale

The SecurityModuleAdminTool is getting bigger and broader in scope. It won't be fully implemented for Gutsy. Let's focus on AppArmor support in Gutsy.

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.

Assumptions

Design

We need to focus on :

• providing good profiles that works out of the box for the default configuration.

• simple command line tools to manage applied profiles. They should provide the functionalities defined in SecurityModuleAdminTool.

Implementation

Into main

• get apparmor packages into main : MainInclusionProcess

  • write a main inclusion report : MainInclusionReportApparmor.

  • remove aa-eventd and Report.pm from the package as their dependencies are not included into main. OK

  • raised issues:

    • need manual compilation : OK - Included in linux-ubuntu-modules.

    • profiles not well tested : ship with a small amount of profiles enabled, all in complain mode from universe.
    • split profiles and infrastructure into two different source packages:

      • include infrastructure into main OK

    • include profiles into universe OK

    • perfomance impact when the module is loaded but no profiles are loaded.

  OK

• get apparmor packages into the seeds : SeedManagement

  • include infrastructure into standard seed.

  OK

Kernel module

• Need to include apparmor in the default kernel for gutsy. OK : Included in linux-ubuntu-modules.

• Need to load the apparmor module in the initrd - OK

Good profiles

Widespread testing

• ship profiles in complain mode at first (in order to avoid the FC2 disaster when selinux was shipped in strict by default and nothing was working anymore). OK - 2.0.1+510.dfsg-0ubuntu9

• improve user guide at AppArmor User guide.

  • add section about reporting bug with profiles. bug should be reported in LP against apparmor, not the application.
  • update bugsquad documentation to deal with profiles. Talk with QA team.
• involve the community :
  1. send email on ubuntu-server, ubuntu-hardened.
  2. send email to ubuntu-devel-annouce, fridge-devel.
  3. section in UWN.
• provide packages for feisty :
  • Check if people are actually interested into apparmor on feisty.
  • kernel modules for feisty kernels.
  • other apparmor packages built for feisty. Could be done via :
    • backport : more official, may be to slow for development and profile testing.
    • apt repository on people.ubuntu.com. Look into PPA.

Test plan

Testing is tracked on the AppArmor testing plan wiki page.

Writing profiles

• Try to support FHS when adding access to path.

Administration tools

Command lines tools based on the current apparmor perl scripts found in apparmor-utils.

Features :

• Enable/Disable security framework :
  • via apparmor rc script.
  • update rcS.d/ to reflect change after reboot.

  • OK - command lines documented in AppArmor User guide

• Show security framework status :
  • via apparmor_status script.

  • list loaded security profiles and their mode : OK - patch sent upstream - in 2.0.1+510.dfsg-0ubuntu7

  • list services that are protected by a profile and their mode : OK - patch sent upstream - in 2.0.1+510.dfsg-0ubuntu7

  • list services that have a profile defined but which is not applied : OK - patch sent upstream - in 2.0.1+510.dfsg-0ubuntu7

  • summarize how many policy violations have been reported for each service :
    • Relies on the logging infrastructure. Upstream plans to have a log parsing library. First release in svn trunk. C library with binding for perl, python (via swig).
• Enable/Disable on per service basis : security profiles can be applied to individual service.
  • Two scripts (enforce,complain) are provided in apparmor-utils to change the mode of the profile. However there a no script to enable/disable a profile. Write two scripts to do that :
    • aa-enable to apply a profile.
    • aa-disable to disable a profile.
    This may not be needed. Disabling a profile can be done by putting the profile in complain mode. The only difference then is that log files may be full of audit messages. But the application should work. There may be a performance penalty (logging lot of audit messages for a application which profile is totally wrong). A way to completely disable a profile should be provided. So that user can turn off a profile quickly when their log files are filled with audit messages.

    OK - documented in AppArmor User guide : handle enabled/disabled profiles via symlinks in /etc/apparmor.d/disable/.

• Put all profiles into complain/enforce mode.

  • update AppArmor User guide page to explain how to put all profiles into complain/enforce mode with one command line.OK

• Logging infrastructure.

  AppArmor uses the audit kernel subsystem :

  • aa-eventd from apparmor-utils scans the log files for apparmor audit messages and dumps them into a sqlite database. It can also send notification by email if configured to do so.

    Requires to include packages from universe. See LP#116921

  • auditd : package is in universe for gutsy. General audit daemon which support SELinux events, but apparmor support is very basic. Upstream plans to implement event dispatching, a plugin framework and realtime notification.

    Long term solution.

    • Write an MIR for audit package.
  • do nothing : by default audit messages are sent to syslog if auditd is not running. They are then logged in /var/log/messages.

    Short term solution, for gutsy.

• Notify user of policy violation.
  • User notification :
    • Asynchronous :
      • via logcheck.
    • Realtime :
      • via email.

Scripts should be developed in cooperation with upstream. Thus, they should be written in perl.

AppArmor user guide

AppArmor User guide page should be improved :

• add a usage section to how basic tasks can be performed. OK

• add a debug section : what to do if profiled applications stop working :
  • get the list of policy violations.
  • generate an updated profile for the daemon.
  • send the new profile to the maintainer to update the packaged profile if necessary.

• move UsingAppArmor to the community help wiki.OK

Outstanding Issues

BoF agenda and discussion

---

CategorySpec