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

[Steve Grubb]

On Tuesday, July 09, 2013 06:51:43 PM LC Bruzenak wrote:
> On 07/09/2013 05:24 PM, Steve Grubb wrote
> 
> ...
> 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. ...
> 
> 
> Question - from the title I had thought this was a good thing. But wasn't
> loginuid (and subsequently auid) already immutable? Sorry; just not certain
> what this change does for the average guy...

Currently its a compile time option. This means when its selected the auid is 
immutable and you have a strong assurance argument that any action by the 
subject really is the subject's account. Strong assurance may be required for 
high assurance deployments. It would be more solid standing up in court as 
well because the argument can be made that whatever action occurred can be 
attributed to the subject because there is no way to change it. Its tamper-
proof.

The change means the default policy will now allow process with 
CAP_AUDIT_CONTROL to change the auid to anything at anytime and then perform 
actions which would be attributed to another user. There is an event logged on 
setting the loginuid, so it could be considered tamper-evident. At least as 
long as the event's not filtered or erased.

My preference is that we have a way that we can put the system into the 
immutable mode in a way that leaves no doubts about whether the system has 
operated under the same policy from beginning to end.

-Steve