Add AppArmor policy for the docker binary #14864
Conversation
Wraps the engine itself with an AppArmor policy. This restricts what may be done by applications we call out to, such as 'xz'. Significantly, this policy also restricts the policies to which a container may be spawned into. By default, users will be able to transition to an unconfined policy or any policy prefaced with 'docker-'. Local operators may add new local policies prefaced with 'docker-' without needing to modify this policy. Operators choosing to disable privileged containers will need to modify this policy to remove access to change_policy to unconfined. Signed-off-by: Eric Windisch <eric@windisch.us>
|
LGTM 👍 |
|
(Am I interpreting you correctly that this'll help stop profiles like |
|
@tianon no, that is fixed in PR #14855 This PR will eliminate certain attacks against the docker daemon itself. For instance, if we applied this retroactively to 1.3.x it would remediate CVE-2014-9357 (xz execution). If we had had this policy then, that vulnerability would not have affected AppArmor users. |
|
LGTM |
Add AppArmor policy for the docker binary
|
docker top invokes /bin/ps. Is there a particular reason why this tool hasn't been added? Besides having to extend the ptrace statements in the main profile, the following one adds the /bin/ps subprofile and removes a couple of DENIED from the audit log. profile /bin/ps { |
|
@stefanberger this has now merged, so we should take that as a PR. (I'm not seeing any denials with 'docker top' currently, however?) Also, I'd really like to add delegates to this profile but was unable to make it work on AppArmor 2.8. That will allow removing the attach_disconnected statement and will make this much more secure... |
|
@ewindisch I am using Ubuntu 14.04.2 -- what about you ? |
|
@stefanberger same OS. Lets register an issue and discuss there. |
|
I sent a PR for you to look at the diffs. |
Wraps the engine itself with an AppArmor policy.
This restricts what may be done by applications
we call out to, such as 'xz'.
Significantly, this policy also restricts the policies
to which a container may be spawned into. By default,
users will be able to transition to an unconfined
policy or any policy prefaced with 'docker-'.
Local operators may add new local policies prefaced
with 'docker-' without needing to modify this policy.
Operators choosing to disable privileged containers
will need to modify this policy to remove access
to change_policy to unconfined.
Signed-off-by: Eric Windisch eric@windisch.us