The current docker-default AppArmor profile intends to block write
access to everything in `/proc`, except for `/proc/<pid>` and
`/proc/sys/kernel/shm*`.
Currently the rules block access to everything in `/proc/sys`, and do
not successfully allow access to `/proc/sys/kernel/shm*`. Specifically,
a path like /proc/sys/kernel/shmmax matches this part of the pattern:
deny @{PROC}/{[^1-9][^0-9][^0-9][^0-9]* }/** w,
/proc / s y s / kernel /shmmax
This patch updates the rule so that it works as intended.
Closes#39791
Signed-off-by: Phil Sphicas <phil.sphicas@att.com>
Otherwise if you try to kill a container process from the host directly,
you get EACCES. Also add a comment to make sure that the profile code
(which has been replicated by several projects) doesn't get out of sync.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
In newer kernels, AppArmor will reject attempts to send signals to a
container because the signal originated from outside of that AppArmor
profile. Correct this by allowing all unconfined signals to be received.
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Signed-off-by: Aleksa Sarai <asarai@suse.de>
These files don't exist under proc so this rule does nothing.
They are protected against by docker's default cgroup devices since they're
both character devices and not explicitly allowed.
Signed-off-by: Tycho Andersen <tycho@docker.com>
ExecPath isn't used by anything, and the signal apparmor rule isn't used
because it refers to a peer that we don't ship.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Ubuntu ships apparmor_parser 2.9 erroniously as "2.8.95". Fix the
incorrect version check for >=2.8, when in fact 2.8 deosn't support the
required feature.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Using {{if major}}{{if minor}} doesn't work as expected when the major
version changes. In addition, this didn't support patch levels (which is
necessary in some cases when distributions ship apparmor weirdly).
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Phil Sphicas