[apparmor] AppArmor - dac_override questions

[John Johansen]

On 10/23/2015 02:23 PM, SZIGETVÁRI János wrote:
> Hello everyone,
> 
> I have encountered an interesting situation, where I was asked to correct a user-created AppArmor ruleset for syslog-ng.
> I'm kind of new to AppArmor, although I have some degree of experience with SELinux, so most of the concepts of AA don't sound so foreign to me.
> The point of the whole thing would be to run syslog-ng (not the open-source version) in a custom non-system user account, however, the custom AA policy doesn't seem to work well yet.
> 
> The relevant part of the AA profile looks like this:
> 
> ======
> #include <tunables/global>
> 
> /opt/syslog-ng/libexec/syslog-ng flags=(complain) {
>         #include <abstractions/base>
>         #include <abstractions/consoles>
>         #include <abstractions/nameservice>
>         ...
>         audit capability dac_override,
>         ...
>         audit capability syslog,
>         ...
>         audit /proc/kmsg r,
> ======
> 
> When I run syslog-ng, I get an error message that syslog-ng is unable to access /proc/kmsg:
> 
> $ /opt/syslog-ng/sbin/syslog-ng -Fedv -u syslog -g syslog -f /opt/syslog-ng/etc/syslog-ng.conf
> ...
> [2015-10-23T16:35:56-0400] Finishing include; content='source confgen system', depth='1'
> [2015-10-23T16:35:56-0400] Error opening file for reading; filename='/proc/kmsg', error='Permission denied (13)'
> [2015-10-23T16:35:56-0400] Error initializing source driver; source='s_all', id='s_all#1'
> [2015-10-23T16:35:56-0400] Closing log transport fd; fd='6'
> [2015-10-23T16:35:56-0400] Error initializing message pipeline;
> $
> 
> Of course /proc/kmsg is owned by root:root, and has 0400 access-rights set.
> The interesting thing is that when I look at the kernel logs, I see the following:
> 
> ======
> [127951.664275] type=1400 audit(1445632556.846:970): apparmor="ALLOWED" operation="file_mmap" profile="/opt/syslog-ng/libexec/syslog-ng//null-47//null-48//null-4b" name="/lib/x86_64-linux-gnu/libc-2.19.so <http://libc-2.19.so>" pid=2450 comm="cat" requested_mask="mr" denied_mask="mr" fsuid=101 ouid=0
> [127951.664459] type=1400 audit(1445632556.846:971): apparmor="ALLOWED" operation="file_mprotect" profile="/opt/syslog-ng/libexec/syslog-ng//null-47//null-48//null-4b" name="/bin/cat" pid=2450 comm="cat" requested_mask="r" denied_mask="r" fsuid=101 ouid=0
> [127951.664474] type=1400 audit(1445632556.846:972): apparmor="ALLOWED" operation="file_mprotect" profile="/opt/syslog-ng/libexec/syslog-ng//null-47//null-48//null-4b" name="/lib/x86_64-linux-gnu/ld-2.19.so <http://ld-2.19.so>" pid=2450 comm="cat" requested_mask="r" denied_mask="r" fsuid=101 ouid=0
> [127951.664649] type=1400 audit(1445632556.846:973): apparmor="ALLOWED" operation="open" profile="/opt/syslog-ng/libexec/syslog-ng//null-47//null-48//null-4b" name="/usr/lib/locale/locale-archive" pid=2450 comm="cat" requested_mask="r" denied_mask="r" fsuid=101 ouid=0
> [127951.664661] type=1400 audit(1445632556.846:974): apparmor="ALLOWED" operation="getattr" profile="/opt/syslog-ng/libexec/syslog-ng//null-47//null-48//null-4b" name="/usr/lib/locale/locale-archive" pid=2450 comm="cat" requested_mask="r" denied_mask="r" fsuid=101 ouid=0
> [127951.670498] type=1400 audit(1445632556.854:975): apparmor="AUDIT" operation="getattr" profile="/opt/syslog-ng/libexec/syslog-ng" name="/proc/kmsg" pid=2443 comm="syslog-ng" requested_mask="r" fsuid=101 ouid=0
> ======
> 
> The last log entry says that syslog-ng ran a getattr system call on /proc/kmsg, and there are no more audit logs after that, and so there is no DENY log either.
Right so the kernel does multiple permission checks, capability, DAC, LSM, and any additional knobs people have decided to add for systems that don't use an LSM. It is entirely possible to have 6 different levels of checks happening for some operations, and the ordering is not always stable.  ie. for some LSM hooks the DAC check comes first, for others the LSM check comes first and then the DAC

> So it seems to me, that it's not AppArmor that's preventing syslog-ng from accessing /proc/kmsg, but something else. And that is weird for me, because the profile contains capability dac_override, which should allow the running syslog-ng instance to circumvent the stabdard Linux DAC file access controls.
> 
> Also, it may be worth explicitly saying, that the profile matches the running process. By that I mean that when I comment out the config line which makes syslog-ng try to open /proc/kmsg, then the process listing of "ps auxwfZ" shows that syslog-ng receives the /opt/syslog-ng/libexec/syslog-ng label.
> 

It is likely being caused by /proc/sys/kernel/dmesg_restrict which can provide further restrictions on access to dmesg/kmsg