[apparmor] [profile] /etc/cron.daily/logrotate: new rules, capability, permission - the final profile updates and version?

[daniel curtis]

Hello

I'm writing this message, because I would like to, at last, finish
logrotate profile updates. It's near the end. I hope so. Please read my
post and help me with made a decisions. Especially with changing 'Ux' to
'PUx' mode for some rules and the matter of change access mode for
"/usr/sbin/invoke-rc.d". (For now, it's "mrix," but it is responsible for
many log entries, so it definitely should be changed to, for example,
'PUx'. See below.)

Since last year, I'm trying (with a great help from Mr Seth Arnold and
Christian Boltz, thanks!) 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 logrotate profile worked OK. Unfortunately, it turned
out, that it was not all. Another tests showed, that we need add some new
rules. For example:

✓ capability setgid,
✓ /etc/rc?.d/ r,
✓ /etc/default/rsyslog r,
✓ /usr/bin/xargs mrix,
✓ /bin/echo mrix,

And so on. However, new capability is also needed. (Which is: "capability
setgid,") Next issue; Mr Seth Arnold suggested 'Ux' mode for two rules:
"/{usr/,}sbin/initctl" and "/{usr/,}sbin/runlevel" [1]. But, "Ux" is not
really a secure solution, right? "Ux" mode should be used in a very special
cases. Am I right? With this mode in use, processes runs without any
AppArmor protection.

Why am I mentioning it? Because at least two rules in a logrotate profile
contains such an access. (Please see; "initctl" and "runlevel" above.)
According to several AppArmor's documentations, this option introduces a
security vulnerability, that could be used to exploit AppArmor.

Of course 'Ux' can be used, but as a last resort. I would like to ask if
'PUx' mode is not more secure solution? What do you think? Can it be
changed in a logrotate  profile? I'm just asking. Nothing more, nothing
less. (Mr Seth Arnold answer about "Ux" - see [3b])

Anyway, tests shows, that "invoke-rc.d" with "mrix," access mode produce
many DENIED actions. Log files contains several entries related to this
issue. 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

As we can see, "mrix," mode for '/usr/sbin/invoke-rc.d' seems to be wrong,
because there are many binary files, to which "invoke-rc.d" is recalled
(see above log entries; there is many more of them.) What about using 'PUx'
mode (which seems to be a better solution from a security point o view.)?
Again: that's only a question. Leaving it as is - using "mrix" mode - will
require to add many new rules (according to a log messages). So, my
proposition is simple:

✗ /{usr/,}sbin/initctl Ux,
✗ /{usr/,}sbin/runlevel Ux,
✗ /usr/sbin/invoke-rc.d mrix,

✓ /{usr/,}sbin/initctl PUx,
✓ /{usr/,}sbin/runlevel PUx,
✓ /usr/sbin/invoke-rc.d PUx,

Generally, "/usr/sbin/invoke-rc.d" access mode should be changed. (And
probably, in all of these rules, "Ux" mode should be using instead of
"PUx".)

If it's OK, then We can change above rules, next add a missing ones (see
above) and logrotate profile should be complete(?) So, what is your opinion
about using 'PUx' instead of 'Ux' mode, also for this rule:
'/usr/sbin/invoke-rc.d'?

Summarizing: logrotate profile needs at least five new rules. If my
propositions are OK, Mr Christian Boltz will be able to update a "new"
profile to e.g.; bazaar.launchpad.net, apparmor v2.X etc. And most
important: it seems, that "/etc/cron.daily/logrotate" was added to the
AppArmor v2.11.1 (see "Policy" subtitle.) [2] Please also see some
important messages [3]

I'm sorry for such a long message, I wanted to describe all the important
things.

Thanks, best regards.
____________________
[1] https://lists.ubuntu.com/archives/apparmor/2016-December/010359.html
[2] http://wiki.apparmor.net/index.php/ReleaseNotes_2_11_1
[3] https://lists.ubuntu.com/archives/apparmor/2017-April/010719.html
[3a] https://lists.ubuntu.com/archives/apparmor/2016-December/010420.html
[3b] https://lists.ubuntu.com/archives/apparmor/2016-December/010359.html
.
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20171025/3d4e8f81/attachment.html>