Re: Filtering out non-interactive users
On Saturday, January 15, 2011 08:39:30 pm PJB wrote:
On Fri, Jan 14, 2011 at 05:21:49PM -0500, Steve Grubb
[sgrubb(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit