On Monday, July 08, 2013 04:51:20 PM Eric Paris wrote:
On Mon, 2013-07-08 at 16:34 -0400, Steve Grubb wrote:
> On Friday, May 24, 2013 12:11:50 PM Eric Paris wrote:
> > This adds a new 'audit_feature' bit which allows userspace to set it
> > such that the loginuid is absolutely immutable, even if you have
> > CAP_AUDIT_CONTROL.
>
> I'm also not sure I like it done this way. What I was thinking about is
> that we should set this at boot so that no matter what happens during
> boot, the policy is for setting loginuid cannot be messed with. We really
> do not want this to be changeable after the system comes up. I'd much
> rather see this as audit=4 on the boot prompt (meaning enabled and
> immutable). This way its clear to everyone that it can only be changed by
> rebooting the system and the policy is in effect for the duration of the
> session.
Linus has explicitly said the kernel command line options are only
acceptable if they are required for kernel functionality before they can
be set by userspace.
I'd say that is the case. If we are going to have immutable loginuid, we don't
want some processes running under one policy and then others later under
another policy. Besides, this isn't adding a boot command. Its already there.
If we don't trust the audit system initialization we already lost
and no
amount of audit= is going to change that.
I'm thinking more about High Assurance cases where the boot
partition/environment is removed from an attacker's reach. Consider use cases
where you want to allow root, but you do not want them to make certain kinds
of changes to the system by taking away certain capabilities in the initramfs
which is outside of the control of anyone with root.
-Steve