Re: [PATCH 7/7] audit: audit feature to set loginuid immutable
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