[PATCH 7/7] audit: audit feature to set loginuid immutable

[Eric Paris]

On Wed, 2013-07-10 at 09:32 -0500, LC Bruzenak wrote:
> On 07/10/2013 08:46 AM, Steve Grubb wrote:
> >
> > Currently its a compile time option. This means when its selected the auid is 
> > immutable and you have a strong assurance argument that any action by the 
> > subject really is the subject's account. Strong assurance may be required for 
> > high assurance deployments. It would be more solid standing up in court as 
> > well because the argument can be made that whatever action occurred can be 
> > attributed to the subject because there is no way to change it. Its tamper-
> > proof.
> That was my understanding.
> >
> > The change means the default policy will now allow process with 
> > CAP_AUDIT_CONTROL to change the auid to anything at anytime and then perform 
> > actions which would be attributed to another user. There is an event logged on 
> > setting the loginuid, so it could be considered tamper-evident. At least as 
> > long as the event's not filtered or erased.
> This sounds dangerous. Why would we want to allow this?

Immutability was first introduced in kernel 3.3.  It wasn't enabled in
the kernel config for Fedora until some time much later.  It is not
present in any enterprise distro that I know of.

Before systemd immutability was not possible.  If an admin logged in and
restarted the sshd daemon the daemon would be running as the admin's
loginuid.  When a new user tried to log in via ssh it would need to
change the loginuid from the admin loginuid to their new loginuid.  We
had to give sshd CAP_AUDIT_CONTROL in order to switch the loginuid.
(ALL loginuid changes required CAP_AUDIT_CONTROL)

When systemd came out I added immutability.  Since restarting sshd in a
systemd world is done by init, which has no loginuid, and thus the new
sshd would have no loginuid.  Thus a user logging in would be able to
set a new loginuid without any permissions.

We learned that admins, for various reasons, really do want to be able
to launch daemons by hand and not via init/systemd.  In particular, we
know of many people who launch containers by hand which allows some form
of login (usually sshd).  With the current loginuid immutable code those
people are UNABLE to log in inside the container.

This patch series allows a privileged task (one with CAP_AUDIT_CONTROL)
the ability to unset their own loginuid.  I allows behavior similar to
the pre 3.3 kernels.  Big different being that the privilege is needed
in a helper to UNSET the loginuid, not in the network facing daemon
(ssh) to SET the loginuid.  The series also allows the 'unsetting'
feature to be disabled and locked so it cannot ever be enabled.

Whew, so now we have background.  Now we can talk about the tamper-proof
vs tamper-evident discussion.  I do not buy tamper-proof at all.  If the
user has CAP_AUDIT_CONTROL claiming tamper-proof-ness is a lie.  They
can auditctl -e0 and win.  Ah, but one might retort, what is someone ran
auditctl -e2.  And I would retort, but good sir, if you ran auditctl -e2
to stop CAP_AUDIT_CONTROL from completely owning the box, why didn't you
set the loginuid immutable first?

Thus far every statement that I have seen about loginuid_immutable being
necessary on the kernel command line does not stand up to scrutiny...

-Eric