Re: [PATCH 7/7] audit: audit feature to set loginuid immutable
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(a)magitekltd.com