Merge lp:~dobey/tarmac/add-apparmor into lp:tarmac
Proposed by
dobey
Status: | Merged |
---|---|
Approved by: | dobey |
Approved revision: | 410 |
Merged at revision: | 412 |
Proposed branch: | lp:~dobey/tarmac/add-apparmor |
Merge into: | lp:tarmac |
Diff against target: |
71 lines (+54/-1) 2 files modified
data/tarmac.apparmor (+50/-0) setup.py (+4/-1) |
To merge this branch: | bzr merge lp:~dobey/tarmac/add-apparmor |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Manuel de la Peña (community) | Approve | ||
Seth Arnold (community) | Approve | ||
Review via email: mp+193323@code.launchpad.net |
Commit message
Add an apparmor profile for tarmac.
Description of the change
This adds an apparmor profile for tarmac, and it's children (as executed by the command.py plug-in). There is probably a lot more the profile could do here, but I don't know apparmor well enough to really lock things down and keep allowing the ability to run arbitrary things (like python/
I think this is a reasonable start though.
To post a comment you must log in.
This is a great start; tarmac's children are confined to the tarmac_child profile, and the broad /** rmix, rule will keep everything confined to that child. The #include <abstractions/ private- files-strict> provides some assurance that tarmac's children won't be able to easily impersonate a developer who might run tarmac.
I am a little worried about the attachment specification "/**/tarmac" -- if tarmac is being packaged probably the full path should be known and used instead. (aa-logprof does not handle these paths well, if I recall correctly, but apparmor_parser and the kernel will handle it fine.) Consider changing this in the future.
Looks great. Thanks!