The apparmor tag was introduced in a01ed80 (2014) to make cgo dependency
on libapparmor optional.
However, the cgo dependency was removed in db093f6 (2017), so it is no
longer meaningful to keep apparmor build tag.
Close#2704
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The `apparmor_parser` binary is not really required for a system to run
AppArmor from a runc perspective. How to apply the profile is more in
the responsibility of higher level runtimes like Podman and Docker,
which may do the binary check on their own.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
This is an additional mitigation for CVE-2019-16884. The primary problem
is that Docker can be coerced into bind-mounting a file system on top of
/proc (resulting in label-related writes to /proc no longer happening).
While we are working on mitigations against permitting the mounts, this
helps avoid our code from being tricked into writing to non-procfs
files. This is not a perfect solution (after all, there might be a
bind-mount of a different procfs file over the target) but in order to
exploit that you would need to be able to tweak a config.json pretty
specifically (which thankfully Docker doesn't allow).
Specifically this stops AppArmor from not labeling a process silently
due to /proc/self/attr/... being incorrectly set, and stops any
accidental fd leaks because /proc/self/fd/... is not real.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
libapparmor is integrated in libcontainer using cgo but is only used to
call a single function: aa_change_onexec. It turns out this function is
simple enough (writing a string to a file in /proc/<n>/attr/...) to be
re-implemented locally in libcontainer in plain Go.
This allows to drop the dependency on libapparmor and the corresponding
cgo integration.
Fixes#1674
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
The creation of the profile should be handled outside of libcontainer so
that it can be customized and packaged.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Akihiro Suda