the meaning of this audit entry

the meaning of this audit entry

[Bill Tangren]

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

Re: the meaning of this audit entry

[Steve Grubb]

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.

> 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"

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.


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

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

Re: the meaning of this audit entry

[Bill Tangren]

On DATE, the author spaketh: Steve Grubb
> 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.

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

RE: the meaning of this audit entry

[Mike Nixon]

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@redhat.com [mailto:linux-audit-bounces@redhat.com]
On Behalf Of Bill Tangren
Sent: Tuesday, November 20, 2007 10:37 AM
To: linux-audit@redhat.com
Subject: Re: the meaning of this audit entry


On DATE, the author spaketh: Steve Grubb
> 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.

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@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
 

Re: the meaning of this audit entry

[Steve Grubb]

On Tuesday 20 November 2007 07:49:00 pm Mike Nixon wrote:
> 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"

You are forgetting the exit code. In this case, it matters. :)

-Steve

Re: the meaning of this audit entry

[Steve Grubb]

On Tuesday 20 November 2007 10:36:47 am Bill Tangren wrote:
> 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

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

Re: the meaning of this audit entry

[Matthew Booth]

[-- Attachment #1.1: Type: text/plain, Size: 2171 bytes --]

Bill,

On Mon, 2007-11-19 at 16:22 -0500, Bill Tangren wrote:
> 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"

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'?

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

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.

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

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: the meaning of this audit entry

[Bill Tangren]

On DATE, the author spaketh: Matthew Booth
> Bill,
>
> On Mon, 2007-11-19 at 16:22 -0500, Bill Tangren wrote:
>> I'd like to know what this audit log entry means:
>>
>> type=SYSCALL msg=audit(1195506796.447:7712726): arch=40000003 syscall=3
>> successo 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"
>
> 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.


Except that it is putting 500MB into the logs every day.


>
> 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'?

Yes, I start with this.

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


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.


>
>> -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
>
> Matt
> --



-- 
Bill Tangren
U.S. Naval Observatory

Re: the meaning of this audit entry

[Steve Grubb]

On Tuesday 20 November 2007 10:08:08 am Bill Tangren wrote:
> 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.

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