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

[LC Bruzenak <lenny@magitekltd.com>]

On 07/10/2013 08:46 AM, Steve Grubb wrote:
>
> 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.
That was my understanding.
>
> 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.
This sounds dangerous. Why would we want to allow this?
>
> 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.
That is a better way.

>From an end user perspective I can tell you that although we strive to
be diligent, the reality of reduced budgets and multi-tasking security
managers means that tamper-proof (at least as a near-to-mid-term goal)
is desired over tamper-evident.
Even if the event is not erased or filtered it means another requirement
levied on a person which I do not believe existed before.

Thanks for the info, Steve. I appreciate it!
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com