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

[Eric Paris]

On Wed, 2013-07-10 at 13:51 -0500, LC Bruzenak wrote:
> On 07/10/2013 01:16 PM, Eric Paris wrote:
> >> > 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.
> 
> Thank you for these details; I really appreciate it.
> 
> As far as restarting daemons - I guess in theory this obviates the
> "run_init" command?
> Or only the uid part of the context?

Correct.  "systemctl start httpd.service" or "service httpd
start" (which just maps to the systemctl command) no longer need
run_init to deal with the SELinux context of init vs sysadm/unconfined.

> And by breaking apart the unsetting (privileged helper) with the setting
> (daemon itself) this is more securely accomplished?

I believe so.  In the RHEL6 way of handling loginuid, we would have to
give CAP_AUDIT_CONTROL inside the container, since sshd inside the
container would need it to allow users to log in (mind you RHEL6 doesn't
have containers, but still)

In this way the helper which creates the container could be given the
priv and CAP_AUDIT_CONTROL would never be granted inside the container
at all.  I believe it's a better design any time network facing daemons
have less privilege.

> Chewing on this a bit...regardless, thanks again for the details; it
> helps tremendously.