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

[LC Bruzenak <lenny@magitekltd.com>]

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?

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

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

LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com