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

LC Bruzenak
2013-07-10T14:32:22Z

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