On Wed, 10 Apr 2019, daniel curtis wrote: > 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,
This is fine.
> 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,
Perhaps:
owner @{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,
This is fine.
> 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,
Less great, but this would be somewhat better:
owner @{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,
This is fine.
> 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,
Uh oh, these two are getting into an area where you are giving logrotate device
ownership, since systemctl is very rich.
> 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,
>
Perhaps just allow:
#include <abstractions/dbus-strict>
> 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,
Does the ptrace show up if you have all the other rules? Oftentimes ptrace
shows up cause the program crashes and there is some sort of crash handling
going on. It could also be caused by the systemctl command since 'trace' is
unfortunately overloaded. Deny would definitely be better, otherwise this gives
logrotate the access to ptrace unconfined root (aka, another means to device
ownership). That said, deny rules make debugging more difficult since people
can't see why something is failing as easily.
> 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?
The least is usually the best.
>
> 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?
Most of the rules are fine. The use of systemctl has me very concerned and begs
the question of the utility of the profile since the policy is at best advisory
at that point.
--
Jamie Strandboge | http://www.canonical.com
signature.asc
Description: PGP signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
