Filtering out non-interactive users

[Steve Grubb]

On Saturday, January 15, 2011 08:39:30 pm PJB wrote:
> On Fri, Jan 14, 2011 at 05:21:49PM -0500, Steve Grubb [sgrubb at redhat.com] wrote:
> > > In older versions of the audit code, we used the following type of
> > > system call auditing rule which seemed to work pretty well:
> > > 
> > > -a exit,always -S creat -S open -S openat -S truncate -S ftruncate -F
> > > success=0 -F auid!=-1
> > 
> > This rule looks correct except that if you have a 64 bit system,  I would
> > suggest a -F arch=b32 between the '-a' and '-S' and then another copy of
> > the rule for the 64 bit arch.
> 
> We are running purely 32-bit systems so I left out the architecture
> filter. However while trying to debug I did add it in and it seemed to
> make no difference.

Right, it would make no difference on a 32 bit system. One possibility, though, I don't 
know how many people actually use 32 bit systems these days and there could be a bug 
that everyone has missed. Another possibility is that some other rule is preventing 
the auditing to work. You might try deleting all rules and then adding just the one 
rule like this:

# auditctl -a exit,always -F arch=b64 -S creat -S open -S openat -S truncate -S 
ftruncate -F success=0 -F auid!=-1 -k unsuccessful

Then after a few minutes:

# ausearch --start recent -k unsuccessful --raw | aureport --summary --file

I get a bunch of files listed for the -ENOENT return code.


> > > Can someone point me to documentation/examples or help me out with the
> > > proper syntax for setting up rules that will exclude the background
> > > processes? We are using auditd 1.7.4 now and the 'auid' filter above no
> > > longer does the job.
> > 
> > There's been a lot of bugs fixed since then. You might try building a
> > newer auditctl and trying it out to see if that makes a difference. Also
> > note that the event capturing is done by the kernel and the kernel
> > version would matter more than the auditd version.
> 
> Unfortunately I'm in one of those situations where changing software
> versions will cause severe heartburn with management and customer types
> due to concerns about baseline stability, so I have to stick with what we
> have right now. The kernel is 2.6.33.1 with no extra patches, as far as I
> know.

That should work unless the is a 32 bit bug everyone has missed or you have another 
rule preventing the logging. If you do cat /proc/self/loginuid, do you get a number > 
0? Also, if you use auid!=4294967295, does that work?

-Steve
 

> > Are you getting other events like logins? Just making sure your disk
> > isn't full or something else. And when you do auditctl -s, it shows the
> > audit system is enabled?
> 
> We are getting CWD, PATH, and SYSCALL audit events in the log, but only
> from files/directories that have an explicit watch set on them. I haven't
> seen any other type of audit event other than those three come through,
> and again only on things that we set explicit watches on.
> 
> Thanks,
> Patrick
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit