[PATCH 7/7] audit: audit feature to set loginuid immutable
LC Bruzenak
lenny at magitekltd.com
Wed Jul 10 18:51:14 UTC 2013
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 at magitekltd.com
More information about the Linux-audit
mailing list