[apparmor] [profile] logrotate: new rules needed.

[daniel curtis]

Hello.

Two years ago, Mr Seth Arnold, Mr Christian Boltz and I, started to work on
Logrotate profile updates, because profile, which was then available did
not have many necessary rules etc. However,  We managed to achieve a
satisfactory result (see 1.)

In the meantime - during various tests - it turned out, that three new
rules are needed. I've written an email, but there was not any answer
(please see 2.) Rules mentioned in a second link are not available in
updated Logrotate profile (see 1.)

So, is there a possibility to add these rules? I'm especially asking Mr
Christian Boltz.

And now very important thing. On Mon., Mar. 25 rsyslog package has been
updated (see 3.) As we can see in a change list, there are some interesting
informations about 'rsyslog-rotate'. Then serious problems started to
happen: log files, such as '/var/log/syslog' were empty all the time and
nothing logged etc. However, 'syslog.1' file contained some  informations
and this helped me with finding the cause.

It turned out that the reason is obvious: AppArmor blocked operations etc.
So, below are logs and rules created based on these entries. (NOTE: adding
these rules helped and everything is okay now; logrotate works as
expected.)

1/
# apparmor="DENIED" operation="exec"
# profile="/etc/cron.daily/logrotate"
# name="/usr/lib/rsyslog/rsyslog-rotate" pid=4988
# comm="sh" requested_mask="x" denied_mask="x"
# fsuid=0 ouid=0
#
/usr/lib/rsyslog/rsyslog-rotate ix,

2/
# apparmor="DENIED" operation="open"
# profile="/etc/cron.daily/logrotate" name="/proc/2054/stat"
# comm="systemctl" requested_mask="r" denied_mask="r"
# fsuid=0 ouid=0
#
@{PROC}/[0-9]*/stat r,

3/
# apparmor="DENIED" operation="open"
# profile="/etc/cron.daily/logrotate"
# name="/proc/sys/kernel/osrelease" comm="systemctl"
# requested_mask="r" denied_mask="r" fsuid=0 ouid=0
#
@{PROC}/sys/kernel/osrelease r,

4/
# apparmor="DENIED" operation="open"
# profile="/etc/cron.daily/logrotate" name="/proc/1/environ"
# comm="systemctl" requested_mask="r" denied_mask="r"
# fsuid=0 ouid=0
#
@{PROC}/[0-9]*/environ r,

5/
# apparmor="DENIED" operation="open"
# profile="/etc/cron.daily/logrotate" name="/proc/cmdline"
# comm="systemctl" requested_mask="r" denied_mask="r"
# fsuid=0 ouid=0
#
@{PROC}/cmdline r,

6/
# apparmor="DENIED" operation="capable"
# profile="/etc/cron.daily/logrotate" comm="systemctl"
# capability=12 capname="net_admin"
#
capability net_admin,

7/
# apparmor="DENIED" operation="connect"
# profile="/etc/cron.daily/logrotate"
# name="/run/systemd/private" comm="systemctl"
# requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
#
/{,var/}run/systemd/private rw,

8/
# apparmor="DENIED" operation="connect"
# profile="/etc/cron.daily/logrotate"
# name="/run/dbus/system_bus_socket" comm="systemctl"
# requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
#
/{,var/}run/dbus/system_bus_socket rw,

And as a last rule: 'ptrace'. This system call can be defined as dangerous
accesses and should not be allowed in most policy. Is this true? It can be
abused - for example - to break out of the seccomp sandbox etc. Anyway, it
seems that after mentioned 'rsyslog' update, logrotate requests 'ptrace
(trace)' rule. Please see below:

9/
# apparmor="DENIED" operation="ptrace"
# profile="/etc/cron.daily/logrotate" comm="systemctl"
# requested_mask="trace" denied_mask="trace"
# peer="unconfined"
#
deny ptrace (trace) peer=unconfined,
#ptrace (trace) peer=unconfined,

As we can see, there are two rules. Because of some doubts about 'ptrace'
call, I decided to make some tests and it seems, that denying 'ptrace
(trace)' doesn't break anything and logrotate works normally. What is your
opinion about this rule? Should it be allowed (see second, hashed rule) or
a better options is to deny such request?

● By the way: what access mode should be used in rule '1/' concerning
'/usr/lib/rsyslog/rsyslog-rotate'? Because logs contained
'requested{denied}_mask=x' I decided to use 'ix' but maybe a better
solution is 'mrix'? What is your opinion?

Summarizing: logrotate profile (see 1.) needs some new rules. Please see 2.
and this message. And one of the most important question, that I want to
ask:

✓ Does logrotate really needs access to '/run/systemd/private'?
✓ (...) needs access to '/run/dbus/system_bus_socket'?
✓ (...) really needs 'net_admin' capability net_admin?
✓ What about access to '/proc/'? (please see above rules).

Sorry for such a long message (and - if it will appear - for bad text
formatting). So, are all these rules really needed? If yes, are they secure
to use?

Thanks, best regards.
______________________
1. https://lists.ubuntu.com/archives/apparmor/2016-December/010388.html
2. https://lists.ubuntu.com/archives/apparmor/2017-April/010719.html
3. https://lists.ubuntu.com/archives/xenial-changes/2019-March/023871.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190410/89c9380d/attachment.html>