[apparmor] AppArmor - dac_override questions
john.johansen at canonical.com
Mon Oct 26 14:36:54 UTC 2015
On 10/24/2015 03:37 PM, Christian Boltz wrote:
> Am Freitag, 23. Oktober 2015 schrieb SZIGETVÁRI János:
>> 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.
Actually no LSM can do this. The LSM on which selinux, apparmor, tomoyo,
smack, yama, are based is purely restrictive when it comes to DAC
permissions. These modules can not override DAC permission checks, the
checks are done by the kernel outside of the LSM.
> Maybe that's where your SELinux knownledge bites you ;-)
> (I don't know much about SELinux, but I know that it puts labels on
> files etc. and then decides about the permissions based on those
true, but the kernel checks DAC before/after calling out to the LSM
apparmor and selinux aren't that different conceptually, its just that
apparmor does its labeling dynamically. Its more a matter of implementation
differences (which hooks are used), and how they have extended their
respective models (TE selinux and DTE for apparmor).
> If I understand your mail right, you are running syslog-ng as a non-root
> user (correct?). Therefore it isn't allowed to read the root-only
> /proc/kmsg, with or without an AppArmor profile.
It is likely due to the /proc/sys/kernel/dmesg_restrict control which
allows restricting access to dmesg/kmesg beyond DAC or the LSM.
> AppArmor never *adds* permissions, it only restricts them.
> This also means that a "capability dac_override," rule is only relevant
> and helpful for processes running as root . Processes running as non-
> root will hit the usual Linux DAC restrictions (+ possibly additional
> restrictions by the AppArmor profile).
> To confirm this, chmod go+r /proc/kmsg and try again. If it works
> afterwards, my guess was right - if not, I was wrong ;-)
Right, the task needs the capability dac_override set, and then the
apparmor check for capability will mask against what is in the profile.
It is possible that apparmor could set a tasks capabilities (this actually
existed experimentally in the past) but it is easy to get wrong and
allows the security policy author to inject security vulnerabilities.
With the expansion of capabilities its even harder to get right, and
so I don't see us adding the ability
More information about the AppArmor