[apparmor] [profile] /etc/cron.daily/logrotate: a couple of DENIED messages.

[Seth Arnold]

Hi Daniel,

On Thu, Nov 10, 2016 at 09:19:21PM +0100, daniel curtis wrote:
> No, I haven't installed any program etc., that try to 'correct' system
> security and so on (not to mention security updates etc.) Strange. But...
> chown(1) command (which you provided) and system restart seems to help - I
> can open these files as a normal user and permission via ls(1) command
> seems to be okay:

I forgot to mention that "normal user" is a bit of a misnomer here;
at least the first user created during the installer is an "administrative
user" -- a member of groups such as sudo, adm, libvirtd, lxd if it's new
enough release, etc., that are roughly root-equivalent through their
powers. Users without these group memberships are probably more deserving
of the name "normal user account".

> $ ls -al /var/log/kern.log
> -rw-r----- 1 syslog adm 78351 Nov 10 20:29 /var/log/kern.log
> $ ls -al /var/log/syslog
> -rw-r----- 1 syslog adm 0 Nov 10 20:33 /var/log/syslog
> 
> Thank You very much; for an answer and for checking a pristine 12.04
> release settings. I forgot to mention an umask(2) setting: it's 077. So,
> maybe umask(2) is responsible for this situation. But I've never seen
> something like this before.

Well, this is a bit complicated:
- an incorrect umask could only affect the permissions
- and logrotate when called by cron ought to be in control of its umask
  anyway

> Anyway, for now I removed /etc/cron.daily/logrotate profile, because of
> this situation and a couple of new DENIED messages. It seems, that
> logrotate also "wants":
> 
> apparmor="DENIED" operation="capable" parent=2875
> profile="/etc/cron.daily/logrotate" pid=2879 comm="logrotate" capability=1
> capname="dac_override"

Logrotate would need this when run as root to manipulate files owned by
syslog.

> apparmor="DENIED" operation="capable" parent=2875
> profile="/etc/cron.daily/logrotate" pid=2879 comm="logrotate" capability=2
> capname="dac_read_search"

Logrotate would need this to manipulate files in directories that would
otherwise be unreadable.

> Should it be included in the profile? If yes: what is the best, secure
> method? And what about this: can you also check those rules?

capability dac_override,
capability dac_read_search,


> /var/log/** rwl,    ## 'l'?

I'm a little surprised about 'l' here but it's presence won't affect the
security of the resulting system -- a process can't use link privileges to
give themselves more access to a file than they would have already had.
(Though they may be able to collude with other processes via this
mechanism. I'd like to see profiles use the "two argument" form of link to
reduce the possibilities here, but it's a fine point.)

> /etc/init.d/* mrix,

If this is needed it might be to ask services to restart after their log
files have been rotated. This could be a serious limitation of the
profile.

> /tmp/logrot* rwl,    ## what is this?
> /tmp w,    ## it's okay?
> /tmp/file* wl,    ## and this one?

Probably temporary storage while compressing files, or sending mail, or
something similar.

> 
> /dev/tty rw,    ## I don't like the 'rw' access for /dev/tty

I think this is only needed for 'interactive' runs of the script, for
error messages. It's probably fine to keep it.

> @{PROC} r,    ## maybe use 'owner'?
> @{PROC}/[1-9]* r,

Probably a bad idea to use 'owner' for these rules -- I'm, again, guessing
that it would want to send signals to programs as it rotates their logs.

> Geez, so much thing... Seth, I'm sorry. If all mentioned things above are
> not needed at all, it seems that logrotate profile is bad.

Well, perhaps not 'bad' so much as 'authored many years ago and not
updated since'. The profile may not reflect modern needs, and it may not
be something that absolutely needs confining.

AppArmor profiles only make sense in terms of a security goal: What
systems are on your computer, how do you want them to interact, and can
you improve security or reliability by reducing the objects they are
allowed to interact with, and how they interact with those objects.

So, depending upon your perspective, logrotate may or may not be worth
confining:

- On the one hand, logrotate doesn't really manipulate the contents of
  files -- it may compress them but that's generally regarded as safe, and
  it renames files, unlinks old files, etc., but again there's not much
  harm with these operations.

- On the other hand, confined services may have only a few places for them
  to write data under the control of attackers, and confining logrotate
  can help ensure that an attacker that has influenced a service can't
  extend their reach very far by infuencing logrotate too.

One thing to keep in mind when writing profiles is that many people choose
to run these services completely unconfined all the time, either because
their distribution of choice doesn't make AppArmor or other MAC systems
easy, or because they don't consider that specific program a viable
threat, or just a lack of time... So even loose profiles can be a large
improvement in safety, relatively speaking. You don't have to be
absolutely perfect to still make an improvement.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161110/ee6ea5eb/attachment.pgp>