Re: [PATCH 7/7] audit: audit feature to set loginuid immutable
On Monday, July 08, 2013 05:32:31 PM Eric Paris wrote:
On Mon, 2013-07-08 at 17:26 -0400, Steve Grubb wrote:
> On Monday, July 08, 2013 04:51:20 PM Eric Paris wrote:
> > 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.
If that's the case, you must be loading the audit policy inside the
initramfs, and thus, you can set this inside the initrd.
I don't think anyone has plans to write those tools at the moment. That would
be ideal. But even in the case where audit rules don't get loaded, there are
audit events generated by the MAC systems and some hard coded kernel events
and user space events. It would be nice to know they are not tampered with.
We MUST have absolute trust until the audit.rules are processed. To
get a
boot option, we have to show how this has value before the audit.rules are
loaded. And it doesn't... Not in any system I can imagine. Nor in the
description you gave above... What am I missing?
I know you want to treat this like SE Linux where audit rules = selinux
policy. SE Linux policy is tightly integrated to the boot process. I'd bet
that if selinux was enabled and loading failed, the system halts. It also
happens very early before other daemons run. The audit system isn't designed
this way. Rules can fail to load and the system still comes up. I'd like to at
least have a way to prevent tampering with loginuid should someone discover a
system like this.
-Steve