Hello.
During last year, I've done some tests (together with Mr Seth Arnold
and Mr Christian Boltz) and I've added a some rules to the default
'/etc/cron.daily/logrotate', because it turned out, that this profile
is very outdated. The profile we have been working on, can be found
for example in 'doc/apparmor-profiles/extras/' folder. Anyway, I'm
writing this message, because I would like to ask some questions and
ask for some suggestions etc.
For almost two years, I'm trying to update '/etc/cron.daily/logrotate'
profile, because it's pretty important to protect, for example, CRON's
tasks with AppArmor profiles. After many changes and helps from Mr
Seth Arnold and Mr Christian Boltz, logrotate profile worked okay.
Unfortunately, it turned out, that some new rules are needed. I did
several tests and we need to add new rules to the profile updated with
all mentioned changes, by Mr Christian Boltz (please [1]):
✓ capability setgid,
✓ /etc/rc?.d/ r,
✓ /etc/default/rsyslog r,
✓ /usr/bin/xargs mrix,
✓ /bin/echo mrix,
Above are rules added last year after some tests with logrotate
profile (I've created a proper thread and I've get an answer about
'/bin/echo' - please see [3] and next message).
Next thing I would like to ask and clarify is an 'Ux' access mode for
two files:
'/{usr/,}sbin/initctl' and '/{usr/,}sbin/runlevel' (for a reason for
such a decision, please see: [2]). But, 'Ux' stands for: "Unconfined
execute mode" and is not really a secure solution, right? This mode
should be used in a very special cases etc.
I would like to ask if 'Ux' could be changed, for example, with 'PUx'
mode? Would not it be a better solution? And what about 'rPUx' (if I
remember correctly, log entries contains 'x' in both
'requested{denied}_mode'). What's your opinion, what do you think
about that?
Why am I mentioning it? Because at least two rules in a logrotate
profile contains such an access. According to several AppArmor's
documentations, this option introduces a security vulnerability, that
could be used to exploit AppArmor etc. I would like to ask if 'PUx'
mode is not more secure solution? But maybe I'm panicking too much...?
I'm aksing about using 'PUx/rPUx' instead of 'Ux' because the 'Ux' -
and 'Px' also - "modes will use the kernel's unsafe exec facility to
instruct glibc to clean the environment. 'Ux' (and other variants
also, such as: 'Px', 'px', 'ux'), change the privileges available to
the process, much like 'setuid' or 'setgid'. Cleaning the environment
helps protect against e.g. LD_PRELOAD abuse" etc. But, does it have
any meaning for 'logrotate'?
So, which access mode should be used for these two rules:
'/{usr/,}sbin/initctl', '/{usr/,}sbin/runlevel' (both with 'Ux' mode;
see profile). Anyway, tests showed, that 'invoke-rc.d' rule with
'mrix,' access mode is responsible many "DENIED" actions. Log files
contains several entries. Some examples:
✗ apparmor="DENIED" operation="exec"
profile="/etc/cron.daily/logrotate" name="/bin/which" pid=2592
comm="invoke-rc.d" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
✗ apparmor="DENIED" operation="exec"
profile="/etc/cron.daily/logrotate" name="/bin/systemctl" pid=2593
comm="invoke-rc.d" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
✗ apparmor="DENIED" operation="exec"
profile="/etc/cron.daily/logrotate" name="/usr/bin/basename" pid=2595
comm="invoke-rc.d" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
Additionally, 'mrix,' mode produces many '/null-/' entries in
'aa-status(8)' command results:
✗ /etc/cron.daily/logrotate
✗ /etc/cron.daily/logrotate//null-/bin/grep
✗ /etc/cron.daily/logrotate//null-/bin/plymouth
✗ /etc/cron.daily/logrotate//null-/bin/readlink
✗ /etc/cron.daily/logrotate//null-/bin/run-parts
✗ /etc/cron.daily/logrotate//null-/bin/systemctl
✗ /etc/cron.daily/logrotate//null-/bin/which
✗ /etc/cron.daily/logrotate//null-/sbin/start-stop-daemon
As we can see, 'mrix' mode for '/usr/sbin/invoke-rc.d' seems to be
wrong solution. There are two conclusions:
1/ change 'mrix' to 'Ux' access mode (or another variants, such as:
'PUx/rPUx');
2/ create rules for all above files using 'mrix' access mode (for
example, log files contain a "DENIED" entry for '/bin/systemctl' with
'x' in 'requested{denied}_mask' but it will be discussed later.);
As we can see, some changes are needed because with 'mrix' access mode
for 'invoke-rc.d', logrotate is not working correctly - log files are
not rotated etc. However, after changing 'mrix' to 'Ux' everything
started to work okay. But what about using 'PUx/rPUx' access mode
(please see above)?
Here are some of my inference, based on the situation, logrotate
tests, log entries etc.:
I've done some new tests in the last couple of days (not to mention
tests from last year, months and so on) and it seems, that logrotate
needs a new capability (see below) and 'abstractions/nameservice' rule
is not even needed, because logrotate needs an access to three files
only: '/etc/{passwd,group,nsswitch.conf}'. However, tests with an
'audit deny /etc/nsswitch.conf' showed, that logrotate works without
this file - logs are rotated and so on.
Each mentioned file is in "nameservice" abstraction, which contains
many rules that are not needed for logrotate and, in some sense,
reduce security, because 'nameservice' allow, for example, TCP/UDP
network access (for both protocols: IPv4/6) and many, many more. So, I
propose to remove 'abstractions/namservice' and use rule/s for
mentioned two files. And I'm proposing such change:
✓ deny /etc/nsswitch.conf r,
✓ /etc/{passwd,group} r,
✗ By the way: if it's about 'invke-rc.d' and changed access mode to
'Ux' - on May, 22. a "DENIED" entry appeared in log files related to:
'name="/bin/systemctl" comm="sh"' with 'requested{denied}_mask=x'. I'm
wondering why it happened ('/bin/systemctl' can be see in
'aa-status(8)' command result! See above; '/null-/' results etc.) -
access mode for 'invokde-rc.d' has been changed, what caused the
disappearance of '/null-/' entries.
Summarizing: logrotate profile needs new rules. With these changes,
everything seems to work okay. (But sometimes there are new "DENIED"
entries). I think that these rules should be added to the profile,
which has been updated by Mr Christian Boltz (please see [1]).
Here are changes made to the '/etc/cron.daily/logrotate' profile,
based on a various tests etc. The rest of the needed rules are above:
✗ include <abstractions/nameservice>
✓ capability setuid,
✓ deny /etc/nsswitch.conf r,
✓ /etc/passwd r,
✓ /etc/group r,
✗ /usr/sbin/invoke-rc.d mrix,
✓ /usr/sbin/invoke-rc.d Ux,
I'm _so_sorry_ about the length of my message, but because during the
last year, months and tests a lot of things has changed. If everything
is okay, and suggested changes are proper then Mr Christian Boltz will
be able to update a working profile to e.g.; bazaar.launchpad.net,
apparmor v2.11, rev. 3614 and profiles/extras folder etc.
== APPENDIX:
==========
One more thing: now, logrotate profile contains rules for
'/var/lib/privoxy/log/' and '/var/lib64/privoxy/log/'. I think it can
be changed with one simple rule:
✓ /var/lib{,64}/privoxy/log/** rwl,
There is also a five rules for files, needed by logrotate, in '/etc/'
folder. These rules can be easily changed with one rule. Let's see:
✗ /etc/cron.daily/logrotate r,
✗ /etc/logrotate.conf r,
✗ /etc/logrotate.d/ r,
✗ /etc/logrotate.d/* r,
✗ /etc/lsb-base-logging.sh r,
And there can be just one rule (it's even easier, because there is
'read' ('r') access neede. So:
✓ /etc/{cron.daily,logrotate.conf,logrotate.d,lsb-base-logging.sh}/* r,
But maybe I'm wrong? If yes, I'm sorry but I used similar rules in
'lightdm/light-locker' profile and it's a lot easier etc. At the very
end, here is an overview of all things I would like to ask
✓ remove 'abstractions/nameservice' (logrotate needs an access to
three files only so, the whole 'nameservice' is not needed;
✓ change access mode for '/{usr/,}sbin/invoke-rc.d' from 'mrix' to
'Ux' (or to 'PUx/rPUx' - it depends on others opinions etc.);
✓ rules simplification (see above one-liner);
** NOTE: If it's needed I can paste diff(1), compare profiles line by
line with a new rules and changes.
Thanks, best regards.
_____________________
[1] https://lists.ubuntu.com/archives/apparmor/2016-December/010420.html
[2] https://lists.ubuntu.com/archives/apparmor/2016-December/010359.html
[3] https://lists.ubuntu.com/archives/apparmor/2017-February/010522.html
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
