Support autogenerating apparmor profiles from declarative templates
Rationale:
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.
Goal:
Create a debhelper addon that supports generating confinement profiles.
Blueprint information
- Status:
- Not started
- Approver:
- Steve Langasek
- Priority:
- Medium
- Drafter:
- Stéphane Graber
- Direction:
- Needs approval
- Assignee:
- Dimitri John Ledkov
- Definition:
- Pending Approval
- Series goal:
- Accepted for raring
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
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.
Risks:
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-
- dh_containment to be a per binary "settings"/tags, e.g. debian/
- 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-
logger: access-system-logs
game-*-bla: private-dirs
<TARGET>: policies
== xnox - low level ==
apparmor: template=
apparmor: policy-
apparmor: /opt/foo/bin/FooApp
<TARGET>: <OPTION> <VARIABLES>
== stgraber ==
/path/to/binary: access-
/path/to/binary: networking unixsocket ipv4 ipv6
/path/to/binary: networking-all
/path/to/binary: my-other-
"/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
