- Ubuntu 16.04
- Linux 4.4.0-97-generic
- AppArmor 2.10.95
- Apache 2.4.18
I'm trying to confine my Apache server with AppArmor hats. I have a hat named "twiki", and set this name in Apache like this:
<Directory "/var/www/twiki">
Require all denied
AAHatName twiki
</Directory>
I added this hat to /etc/apparmor.d/usr.sbin.apache2:
^twiki flags=(complain) {
#include <abstractions/base>
#include <abstractions/apache2-common>
#include <abstractions/perl>
/var/www/twiki/** r,
...
}
The following hats are defined:
twiki
REFBASE
DEFAULT_URI
HANDLING_UNTRUSTED_INPUT
When Apache enters the "/var/www/twiki" directory, it doesn't change to the twiki hat, but instead creates a new hat I didn't configure before:
$ sudo grep -i apache /sys/kernel/security/apparmor/profiles
/usr/sbin/apache2 (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/view (complain)
/usr/sbin/apache2//twiki (complain)
/usr/sbin/apache2//REFBASE (complain)
/usr/sbin/apache2//HANDLING_UNTRUSTED_INPUT (complain)
/usr/sbin/apache2//DEFAULT_URI (complain)
That happens when I open /var/www/twiki/bin/view in my browser, but also for different files. In my understanding of man mod_apparmor, apache should use the twiki hat, or at least fall back to the default hat, but never create new hats.
This is what dmesg shows:
[ 2303.271816] audit: type=1400 audit(1507820233.490:3647): apparmor="ALLOWED" operation="exec" profile="/usr/sbin/apache2" name="/var/www/twiki/bin/view" pid=2021 comm="apache2" requested_mask="x" denied_mask="x" fsuid=33 ouid=33 target="/usr/sbin/apache2//null-/var/www/twiki/bin/view"
[ 2303.273218] audit: type=1400 audit(1507820233.490:3648): apparmor="ALLOWED" operation="file_inherit" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/var/log/apache2/error.log" pid=2021 comm="view" requested_mask="a" denied_mask="a" fsuid=33 ouid=0
[ 2303.274259] audit: type=1400 audit(1507820233.494:3649): apparmor="ALLOWED" operation="open" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/etc/ld.so.cache" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.274321] audit: type=1400 audit(1507820233.494:3650): apparmor="ALLOWED" operation="open" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/lib/x86_64-linux-gnu/libdl-2.23.so" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.274451] audit: type=1400 audit(1507820233.494:3651): apparmor="ALLOWED" operation="open" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/lib/x86_64-linux-gnu/libm-2.23.so" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.274570] audit: type=1400 audit(1507820233.494:3652): apparmor="ALLOWED" operation="open" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.274698] audit: type=1400 audit(1507820233.494:3653): apparmor="ALLOWED" operation="open" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/lib/x86_64-linux-gnu/libc-2.23.so" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.274847] audit: type=1400 audit(1507820233.494:3654): apparmor="ALLOWED" operation="open" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/lib/x86_64-linux-gnu/libcrypt-2.23.so" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.275487] audit: type=1400 audit(1507820233.494:3655): apparmor="ALLOWED" operation="file_mprotect" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/usr/bin/perl" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
[ 2303.275509] audit: type=1400 audit(1507820233.494:3656): apparmor="ALLOWED" operation="file_mprotect" profile="/usr/sbin/apache2//null-/var/www/twiki/bin/view" name="/lib/x86_64-linux-gnu/ld-2.23.so" pid=2021 comm="view" requested_mask="r" denied_mask="r" fsuid=33 ouid=0
So Apache is running under the newly creates hat. After opening some websites, I have many more hats:
$ sudo grep apache /sys/kernel/security/apparmor/profiles
/usr/sbin/apache2 (complain)
/usr/sbin/apache2//null-<MYSERVERHOSTNAME> (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/save (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/rest (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/edit (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/viewfile (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/view (complain)
/usr/sbin/apache2//null-/var/www/twiki/bin/view//null-/bin/grep (complain)
/usr/sbin/apache2//twiki (complain)
/usr/sbin/apache2//REFBASE (complain)
/usr/sbin/apache2//HANDLING_UNTRUSTED_INPUT (complain)
/usr/sbin/apache2//DEFAULT_URI (complain)
This is what apaches error.log says when accessing a file(loglevel debug):
[Thu Oct 12 16:57:14.601547 2017] [apparmor:debug] [pid 2011] mod_apparmor.c(159): [client <MYIP>] [dcfg] adding hat 'twiki' to aa_change_hat vector
[Thu Oct 12 16:57:14.601563 2017] [apparmor:debug] [pid 2011] mod_apparmor.c(178): [client <MYIP>] [scfg] adding server_name '<MYSERVERHOSTNAME>' to aa_change_hat vector
[Thu Oct 12 16:57:14.601567 2017] [apparmor:debug] [pid 2011] mod_apparmor.c(184): [client <MYIP>] [vhost+uri] adding vhost+uri '<MYHOSTNAME>-/twiki/pub/Main/WebPreferences/favic
[Thu Oct 12 16:57:14.601571 2017] [apparmor:debug] [pid 2011] mod_apparmor.c(189): [client <MYIP>] [uri] adding uri '/twiki/pub/Main/WebPreferences/favicon.ico' to aa_change_hat vector
[Thu Oct 12 16:57:14.601574 2017] [apparmor:debug] [pid 2011] mod_apparmor.c(193): [client <MYIP>] [default] adding 'DEFAULT_URI' to aa_change_hat vector
If you need more information, e.g. complete config files, feel free to ask.
The profile is in complain mode, which means that apparmor is trying to learn the application behavior.
In complain mode if there isn't an exact match apparmor will create empty null learning profiles so that the behavior being learned is not incorrectly attributed to the wrong profile. The learned behavior under the null-XXX profile can then be used to create a new profile or folded into an existing profile. If a non-first choice profile was used in the above situation it would be difficult if not impossible to separate the new behavior from the old if a new profile is desired.
I have had reports that this is new behavior for change_hat. If so its because the old code had a bug in it stopping this from happening, it certainly had the code. However if this is an expected change in behavior we may have to revert to the old incorrect behavior, and make this behavior available through a new flag.