Question on the unset user in audit

[Burn Alting]

Steve,

Thanks for the answer. In essence, one can ignore the unset user
depending on one's appetite for risk and by taking a holistic approach
to monitoring activity in a complete ICT environment.

Rgds


On Tue, 2013-11-05 at 07:51 -0500, Steve Grubb wrote:
> On Tuesday, November 05, 2013 10:19:23 PM Burn Alting wrote:
> > All,
> > 
> > I have seen some audit.rules that ignore ALL events involving auid being
> > the unset user ie a rule segment of
> > 
> > 	-F auid!=4294967295
> > 
> > What are the possible risks of excluding recording events from the unset
> > auid? Especially since I believe root could override the auid by writing
> > to /proc/self/loginuid.
> 
> In talking with agencies like DISA, what they wanted is to identify events 
> originating from users as opposed to normal "system" activities. Meaning that 
> if during startup disks are mounted, its an uninteresting event because its 
> normal startup activity. However, if there is an associated auid >= 500, then 
> its user originating and of interest.
> 
> Should an admin change their auid, there will be an audit event recording that 
> fact. That said, Linux is not designed in any way to guard against a malicious 
> admin. One of the assumptions in Common Criteria is A.NO_EVIL_ADMIN and there 
> are training clauses. But there are some steps that can be taken. On newer 
> kernels there is the object comparator commands '-C' where you can detect 
> abuses of power such as an admin accessing a user's home directory.
> 
> If you are really wanting to use the audit system to even detect signs of 
> compromise, then you can to some extent. You can see apps crashing, you can 
> imagine SE Linux as a defined behavior of applications so that AVC's represent 
> attempts at intrusion, you can also see other attempted changes to the system 
> such as installing executables. But I think at some point the system may be 
> compromised to the point that you can't detect it from the host, you have to 
> have external monitoring and look for suspicious behavior outside the system.
> 
> Not sure if that was the direction you were going with your question. :-)
> 
> -Steve
>