AppArmor (“Application Armor”) is a Linux kernel security module that allows the system administrator to restrict programs’ capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths.
Working on Docker binary to test new deployments to it I have faced some problems on how to disable AppArmor
to docker-default
profile.
It was a bit confusing because I did not see any docker-default
profile into /etc/apparmor.d/
where we usually have them as well.
I have tried to aa-complain
as usage: usage: aa-complain [-h] [-d DIR] [--no-reload] program [program ...]
, however, the [-d DIR] parameter
was not working to /usr/bin/docker
default installation.
Issue:
To set a process to complain mode, use the command line tool
'aa-complain'. To really tear down all profiles, run 'aa-teardown'."
Removing test suite binaries
Makefile:234: recipe for target 'test' failed
make: *** [test] Error 1
Check:
$ root@consul-server:/etc/apparmor.d# aa-status
apparmor module is loaded.
1 profiles are loaded.
1 profiles are in enforce mode.
docker-default
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
I found a related issue in a thread of the Moby Project #33060.
The thread is about the same issue named to Impossible to see contents of AppArmor Profile “docker-default”. Hereto a docker-default
file profile did solve it.
So how I deal with that ?
A generated profile based on a template and be sure the profile is named docker-default
.
Do a copy-paste
to this configuration file in /etc/apparmor.d/docker-default
.
#include <tunables/global>
profile docker-default flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/base>
ptrace peer=@{profile_name},
network,
capability,
file,
umount,
deny @{PROC}/* w, # deny write for all files directly in /proc (not in a subdir)
# deny write to files not in /proc/<number>/** or /proc/sys/**
deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w,
deny @{PROC}/sys/[^k]** w, # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w, # deny everything except shm* in /proc/sys/kernel/
deny @{PROC}/sysrq-trigger rwklx,
deny @{PROC}/kcore rwklx,
deny @{PROC}/mem rwklx,
deny @{PROC}/kmem rwklx,
deny mount,
deny /sys/[^f]*/** wklx,
deny /sys/f[^s]*/** wklx,
deny /sys/fs/[^c]*/** wklx,
deny /sys/fs/c[^g]*/** wklx,
deny /sys/fs/cg[^r]*/** wklx,
deny /sys/firmware/** rwklx,
deny /sys/kernel/security/** rwklx,
}
RUN:
P.S. If you are not root
, make sure to use sudo
within the command:
$ root@consul-server:/etc/apparmor.d# aa-disable /etc/apparmor.d/docker-default
Disabling /etc/apparmor.d/docker-default.
If you don’t have aa-disable
command installed. Run: sudo apt-get install apparmor-utils
.
CHECK:
$ root@consul-server:/etc/apparmor.d# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Now you are able to proceed with whatever you are doing to solve the issue with AppArmor
. Otherwise, make sure you set the profile back to enforce mode so forth.