Support autogenerating apparmor profiles from declarative templates

Registered by Steve Langasek on 2012-10-26

To support the appdev initiative, a new declarative format is wanted, representing the subset of capabilities that third-party apps are allowed to opt into. These declarative files should be converted to apparmor profiles at package build time. Specify a new tool that implements this in idiomatic debhelper fashion.

Create a debhelper addon that supports generating confinement profiles.

Blueprint information

Not started
Steve Langasek
Stéphane Graber
Needs approval
Dimitri John Ledkov
Pending Approval
Series goal:
Accepted for raring
Milestone target:

Related branches



NB! all names of the tools are subject to change / be finalised
NB! policy groups to be defined

User Stories:
An app submitted for the 3rd party repository would like to have elevated permissions to access user/private data or access restricted system resources. In order to to access those, profiles need to be added to the package. Instead of hand-writing complex apparmor profiles, simplified opt-in categories of permissions are offered to the developer.

Incorrect permissions generation - either too much access or not enough. This can be fixed by rebuilding binary package to re-generate corrected permissions.

Release Notes:
For developers, there is now a simplified declarative way to request elevated permissions.
Users now have a simplified way to see exactly which resources third party apps have access to.

Session Notes:
Existing tool to generate profiles from basic policy is aa-easyprof.
* provide a UI to select predefined set of capabilities
* ... which generates "settings file"
* and use aa-easyprof or something else to generate the actual apparmor profile
* Secure WIN! =)

(note, really really use confinement term and not containment)

application-confinement & dh_containment
- dh_containment to be a per binary "settings"/tags, e.g. debian/binary.confinement
- if prefix is, e.g. "apparmor" pipe that through aa-easyprof
- if prefix is something else you have other helpers to extend confinement policy
At the end you get the apparmor profiles for each individual executable.

Suggestions of format:

== xnox - high level ==
mybinary: access-private-photos,
logger: access-system-logs
game-*-bla: private-dirs
<TARGET>: policies

== xnox - low level ==
apparmor: template=com.ubuntu.extras.template
apparmor: policy-groups=user-dirs, system-dirs
apparmor: /opt/foo/bin/FooApp

== stgraber ==
/path/to/binary: access-private-photos
/path/to/binary: networking unixsocket ipv4 ipv6
/path/to/binary: networking-all
/path/to/binary: my-other-abstraction parameter1 parameter2
"/path/to/binary" should be relative to the installation target


Work Items

Work items:
[jdstrand] Get aa-easyprof to read pipe with easyprof syntax as an alternative to command line parameters: POSTPONED
[jdstrand] discuss with stakeholders all possible confinement keywords: POSTPONED
[xnox] define the config syntax with jdstrand for the dh_appconfinement (use debhelper perl lib): BLOCKED
[xnox] Implement new dh_appconfinement debhelper hook, containing the list of confinement policies supported and what tool to call to handle them: BLOCKED

This blueprint contains Public information 
Everyone can see this information.