3:22 p.m.
I'd like to know what this audit log entry means:
type=SYSCALL msg=audit(1195506796.447:7712726): arch=40000003 syscall=3
success=no exit=-11 a0=17 a1=a6c5b80 a2=1000 a3=a6c4d90 items=0 pid=3618
auid=825305204 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="X" exe="/usr/X11R6/bin/Xorg"
It appears that there is a problem with /usr/X11R6/bin/Xorg, and it is
issuing a failed syscall. I can tell you that I see this if there is a
user logged into the console GUI.
The following are the rules that I have that are auditing syscalls:
-a exit,always -S mknod -S acct -S swapon -S sethostname -F success=0 -F
auid=-1 -F auid=0
-a exit,always -S mknod -S acct -S swapon -S sethostname -F success=1
-a exit,always -S settimeofday -S adjtimex -S nfsservctl -S umount2 -S
fdatasync -S setdomainname -F success=0 -F auid=-1 -F auid=0
-a exit,always -S settimeofday -S adjtimex -S nfsservctl -S umount2 -S
fdatasync -S setdomainname -F success=1 -F auid=-1 -F auid=0
-a exit,always -S quotactl -S mount -S kill -S chroot -F success=0 -F
auid=-1 -F auid=0
-a exit,always -S quotactl -S mount -S kill -S chroot -F success=1 -F
auid=-1 -F auid=0
Is this being audited by default, or are one of the previous rules
auditing it?
Thanks!
--
Bill Tangren
U.S. Naval Observatory
4:06 p.m.
On Monday 19 November 2007 04:22:12 pm Bill Tangren wrote:
I'd like to know what this audit log entry means:
It is easier to understand these when you give the '-i' option to ausearch. It
changes things from numeric to text values. It also grounds all records that
make up the event so that you can see all of it.
I'm guessing that this is a failed read syscall that returned -EAGAIN.
ausearch -i would have changed all those numbers to what I put above.
-a exit,always -S mknod -S acct -S swapon -S sethostname -F success=0
-F
auid=-1 -F auid=0
-F options are and'ed together. In this case, they cancel each other out.
None of these rules do anything because the options conflict.
Is this being audited by default, or are one of the previous rules
auditing it?
Hard to say without seeing the whole event that ausearch would output and
seeing what auditctl -l shows.
-Steve
9:36 a.m.
On DATE, the author spaketh: Steve Grubb
For this event:
type=SYSCALL msg=audit(1195572240.060:2971371): arch=40000003 syscall=3
success=no exit=-11 a0=12 a1=97721e8 a2=1000 a3=9782c18 items=0 pid=3538
auid=517 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="X"
exe="/usr/X11R6/bin/Xorg"
I issued this command:
# ausearch -i -a 2971371
type=SYSCALL msg=audit(11/20/2007 10:24:00.060:2971371) : arch=i386
syscall=read success=no exit=-11(Resource temporarily unavailable) a0=12
a1=97721e8 a2=1000 a3=9782c18 items=0 pid=3538 auid=bjt uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=X
exe=/usr/X11R6/bin/Xorg
Now, this system is plugged into a KVM switch, and sometimes the sysadmin
who logs into the GUI stays logged in for days (he forgots to log out),
and the switch is changed to some other system. I don't know if any of
this has anything to do with why I'm getting 500MB worth of logs every
day, but I have noticed that the logs are this big whenever someone is
logged into the GUI.
BTW, this is a RHEL ES 4.6 system.
--
Bill Tangren
U.S. Naval Observatory
6:49 p.m.
Looks to me like someone that was logged in as 'root' attempted but failed
to read a x-windows file. The relevant tipoffs are:
syscall=3 (read)
success=no (failed)
uid=0 (root user account)
comm="X" or exe="/usr/X11R6/bin/Xorg"
Mike
-----Original Message-----
From: linux-audit-bounces(a)redhat.com [mailto:linux-audit-bounces@redhat.com]
On Behalf Of Bill Tangren
Sent: Tuesday, November 20, 2007 10:37 AM
To: linux-audit(a)redhat.com
Subject: Re: the meaning of this audit entry
On DATE, the author spaketh: Steve Grubb
For this event:
type=SYSCALL msg=audit(1195572240.060:2971371): arch=40000003 syscall=3
success=no exit=-11 a0=12 a1=97721e8 a2=1000 a3=9782c18 items=0 pid=3538
auid=517 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="X"
exe="/usr/X11R6/bin/Xorg"
I issued this command:
# ausearch -i -a 2971371
type=SYSCALL msg=audit(11/20/2007 10:24:00.060:2971371) : arch=i386
syscall=read success=no exit=-11(Resource temporarily unavailable) a0=12
a1=97721e8 a2=1000 a3=9782c18 items=0 pid=3538 auid=bjt uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=X
exe=/usr/X11R6/bin/Xorg
Now, this system is plugged into a KVM switch, and sometimes the sysadmin
who logs into the GUI stays logged in for days (he forgots to log out),
and the switch is changed to some other system. I don't know if any of
this has anything to do with why I'm getting 500MB worth of logs every
day, but I have noticed that the logs are this big whenever someone is
logged into the GUI.
BTW, this is a RHEL ES 4.6 system.
--
Bill Tangren
U.S. Naval Observatory
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.2/1142 - Release Date: 11/20/2007
5:44 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.2/1142 - Release Date: 11/20/2007
5:44 PM
8:22 p.m.
On Tuesday 20 November 2007 10:36:47 am Bill Tangren wrote:
Yeah, see this is a wee bit more readable. I think you have a rule for reads
with success != yes. The only thing you might want to worry about is failed
access attempts. They have success=no, but their exit code is different.
Now, this system is plugged into a KVM switch, and sometimes the
sysadmin
who logs into the GUI stays logged in for days (he forgots to log out),
I'd think some auto logout rules would solve that. ;)
I don't know if any of this has anything to do with why I'm
getting 500MB
worth of logs every day,
That is excessive. I think it shows you need to refactor your rules.
-Steve
4:13 p.m.
Bill,
On Mon, 2007-11-19 at 16:22 -0500, Bill Tangren wrote:
arch=40000003 syscall=3 is an i386 read() call. -11 is EAGAIN, which is
a temporary failure. The event itself is nothing to worry about.
However, the audit rules you give below don't appear to specify read(),
so it's not immediately apparent why this would be showing up. The
x86_64 syscall=3 is close(), which you also don't specify. Have you got
any other rules in there which you haven't listed? Do you start your
audit.rules with a '-D'?
Although I haven't specifically tested this, I believe that in every
case below where you've got -F auid=foo -F auid=bar, the rule will never
match. The reason for this is because filters are combined with and, not
or.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
9:08 a.m.
On DATE, the author spaketh: Matthew Booth
Except that it is putting 500MB into the logs every day.
Yes, I start with this.
Well, I'm just finding that out. Obviously I have to rewrite all my rules,
or most of them, anyway. I'd like to blame someone else for the rules,
since I was given these and told to use them, but I should know better.
Obviously I have a lot to learn. I wish there was a tutorial or something
I could read. I've gone over the man page, but I'm not learning enough
from it.
I'll star by splitting up the auid= rules, and observe what shows up in
the logs.
I've tried running the ausearch function, but it can take a really long
time to return, even when I tell it to start only ten minutes ago.
--
Bill Tangren
U.S. Naval Observatory
8:27 p.m.
On Tuesday 20 November 2007 10:08:08 am Bill Tangren wrote:
Take a look at the capp.rules or nispom.rules file in the audit package. Those
are real working rules that have been commented. That is where I would start
if I were setting up a system.
I'll star by splitting up the auid= rules, and observe what shows
up in
the logs.
I think your issues are more fundamental than that. I think you have more
rules than you shared with us and they are looking for unsuccessful calls and
not considering the exit codes. There are plenty of people on this mail list
that could help you with your rules if you told us what kinds of things you
were needing to audit.
-Steve
6351
days inactive
6353
days old
linux-audit@lists.linux-audit.osci.io
8 comments
4 participants
participants (4)
-
Bill Tangren -
Matthew Booth -
Mike Nixon -
Steve Grubb