Question on the unset user in audit

Question on the unset user in audit

[Burn Alting]

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.



Rgds

Re: Question on the unset user in audit

[Steve Grubb]

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

Re: 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
>