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

[Steve Grubb <sgrubb@redhat.com>]

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