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
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
