(no subject)

(no subject)

[Abhishek Gupta]

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

msg=audit(1116360555.329:2401771).

How to interpret above message?what does 1116360555,329,2401771 means here?
By looking at this type of audit message how can i interpret all the things
related to a particular process?
If i want to trace all syscalls called by particular process how to do that
without using ausearch(means by looking at above type messages)
how can i obtain strace output by this this auditing subsystem ?

[-- Attachment #1.2: Type: text/html, Size: 499 bytes --]

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

Re: (no subject)

[Steve Grubb]

On Saturday 12 January 2008 08:45:09 Abhishek Gupta wrote:
> msg=audit(1116360555.329:2401771).
>
> How to interpret above message?what does 1116360555,329,2401771 means here?

seconds.msec:serial number

The seconds can be converted with ctime().


> By looking at this type of audit message how can i interpret all the things
> related to a particular process?

This is not a message type, its just the unique time stamp for the event.


> If i want to trace all syscalls called by particular process how to do that
> without using ausearch(means by looking at above type messages)
> how can i obtain strace output by this this auditing subsystem ?

You would use the autrace program. After running it, it will tell you what 
ausearch command to run to see the results. The output will not be formatted 
like strace, but it contains the information.

If you are writing a program that analyzes the audit data, I'd recommend using 
the auparse library to do all your parsing and data interpretation.

-Steve

(no subject)

[Bill Tangren]

I am running audit-1.0.15-3.EL4 on a RHEL ES 4 system, fully patched. I am
trying to learn the meaning of the output of aureport. For example, if I
want to look at failed events, could you tell me what the following means?
That is, how do I know from this what is failing, and why?



[root@doggett ~]# /sbin/aureport -e --failed -ts yesterday 00:00:00 -te
today 00:00:00

Event Report
===========================
# date time event type auid
===========================
1. 11/01/2007 12:00:00 AM 5844794 SYSCALL -1



TIA,
Bill Tangren

(no subject)

[Henning, Arthur C. (CSL)]

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

RHEL 5

Have two events having difficulty capturing or reviewing with the audit
sub-system.

1. su - "non_existent_account". Using the nispom.rules provided by audit
1.5.6-1. Using various ausearch parameters, am unable to find a
corresponding failure when attempting to "su" to a non-existent account.

2. Non-privileged user attempting to change the date/time on the server.
Of course the user fails to be able to do so, but am unable to capture
or review the event.

Not sure if these are audit rule configuration or search unknowns or
audit sub-system limitations.

Thank you
Art Henning (CSL) 
Enterprise IT Solutions
Northrop Grumman Corporation
art.henning@ngc.com


[-- Attachment #1.2: Type: text/html, Size: 1419 bytes --]

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

(no subject)

[Kirkwood, David A.]

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

How do I place a watch on files that are being rotated? For example: I
want to audit the audit logs themselves , and when they are rotated I
need to watch the new audit log that is created as well as the rotated
logs. 

 

Thanks,

 

David A. Kirkwood



 


[-- Attachment #1.2: Type: text/html, Size: 2124 bytes --]

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

(no subject)

[paul moore]

My understanding is that the auid/loginid process property is to allow the
audit system to *really* know who did things In particular it seems to be
for tracking who did things when they run su or sudo 

But it seems to be trivial to spoof it

login as: paul
paul@192.168.111.40's password:
Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
[paul@rhes5-wa-1 ~]$ sudo bash
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
600[root@rhes5-wa-1 ~]# exit
[paul@rhes5-wa-1 ~]$ cat /proc/self/loginuid
556[paul@rhes5-wa-1 ~]$

I was 556 at login, after sudo i am still 556 but then as root I can now
change it to 600 and the audit log for my actions has auid=600 in it
doesnt that undermine the whole point of the login id?
Surely once it has been set it should not be possible to change it again.

I see a debate in the thread "proc_loginuid_write() checks wrong capability"
about who should be able to do this but it misses the point. It should only
be writtable if its -1 at the moment.
Otherwise it must be unconditionally rejected.

The argument for it being like it is is that root is all powerfull so they
should be allowed to do anything. But the beauty of auid is that it lets me
see who the root sudoer really is. 

(BTW - my 10$ says its should be a new capability since it doesn't match
either CONTROL or WRITE, But if that's not possible then it should be
CONTROL)

Any insights gratefully received

Paul Moore

Re: (no subject)

[Steve Grubb]

On Friday 20 April 2007 18:13:17 paul moore wrote:
> My understanding is that the auid/loginid process property is to allow the
> audit system to *really* know who did things In particular it seems to be
> for tracking who did things when they run su or sudo

Yep.

> But it seems to be trivial to spoof it
>
> login as: paul
> paul@192.168.111.40's password:
> Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
> [paul@rhes5-wa-1 ~]$ sudo bash
> [root@rhes5-wa-1 ~]# cat /proc/self/loginuid
> 556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid

But you will generate an audit message right here saying that you changed the 
loginuid. While its not protection, it doesn't quietly let that occur.

> I was 556 at login, after sudo i am still 556 but then as root I can now
> change it to 600 and the audit log for my actions has auid=600 in it
> doesnt that undermine the whole point of the login id?

There should still be a trail showing that you changed it.

> Surely once it has been set it should not be possible to change it again.

I think there are 1 or 2 daemons that count on that.

> I see a debate in the thread "proc_loginuid_write() checks wrong
> capability" about who should be able to do this but it misses the point. It
> should only be writtable if its -1 at the moment. Otherwise it must be
> unconditionally rejected.

Except in the case where daemons are changing loginuid temporarily to record 
the fact that its doing something on behalf of a user. For example, I think 
postfix may do this when delivering email and reading the dot files.

> The argument for it being like it is is that root is all powerfull so they
> should be allowed to do anything. But the beauty of auid is that it lets me
> see who the root sudoer really is.

But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and 
admin does a restart of sshd, sshd will not be able to set it either. If you 
only allow setting auid if its non-zero, how do you restart a service like 
sshd since it will inherit the loginuid? The only option is to reboot the 
machine, so forget about rpm upgrades.

I really think the answer is to protect this with SE Linux policy...but there 
is a problem. I think that by setting loginuid by the proc filesystem we 
won't be able to have a SE Linux type that is distinct for loginuid without 
changing things in the kernel. Then you also have to worry about descriptors 
being held open across forks. Not to mention, you have to do a open(), 
write(), close() for each setting of loginuid.

So I think the best solution is to make a syscall for setting the loginuid 
that SE Linux can protect with a distinct type. Then we can say things like 
local_login_t is allowed setloginuid_t.

> (BTW - my 10$ says its should be a new capability since it doesn't match
> either CONTROL or WRITE,

I've been saying that for a while too. I think it is distinct in the same way 
that chown is different than unlink. Changing the loginuid is only 1 
attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to 
delete rules. So you change whether or not the event even was recorded as 
opposed to who to blame.

But one thing that does help is deleting the rules is done via netlink 
interface, which SE Linux does control. So, policy can be written that 
disallows anything except auditctl_t from writing to netlink, and policy can 
be written saying who can run auditctl.

-Steve

RE: (no subject)

[paul moore]

Aha - I see that there is an audit event for the auid change. Thats good
enough for me - thanks

I still have a couple of questions

A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why?
There is no error message
B) always if I echo to /proc... as non root it is ignored (as it should be)
but no message is generated; shouldn't it say EPERM?
C) I put pam_loginuid in my gdm pam config but my xterm windows still have
-1 in loginuid (I have rebooted)

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Friday, April 20, 2007 4:32 PM
To: linux-audit@redhat.com
Cc: paul moore
Subject: Re: (no subject)

On Friday 20 April 2007 18:13:17 paul moore wrote:
> My understanding is that the auid/loginid process property is to allow 
> the audit system to *really* know who did things In particular it 
> seems to be for tracking who did things when they run su or sudo

Yep.

> But it seems to be trivial to spoof it
>
> login as: paul
> paul@192.168.111.40's password:
> Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
> [paul@rhes5-wa-1 ~]$ sudo bash
> [root@rhes5-wa-1 ~]# cat /proc/self/loginuid
> 556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid

But you will generate an audit message right here saying that you changed
the loginuid. While its not protection, it doesn't quietly let that occur.

> I was 556 at login, after sudo i am still 556 but then as root I can 
> now change it to 600 and the audit log for my actions has auid=600 in 
> it doesnt that undermine the whole point of the login id?

There should still be a trail showing that you changed it.

> Surely once it has been set it should not be possible to change it again.

I think there are 1 or 2 daemons that count on that.

> I see a debate in the thread "proc_loginuid_write() checks wrong 
> capability" about who should be able to do this but it misses the 
> point. It should only be writtable if its -1 at the moment. Otherwise 
> it must be unconditionally rejected.

Except in the case where daemons are changing loginuid temporarily to record
the fact that its doing something on behalf of a user. For example, I think
postfix may do this when delivering email and reading the dot files.

> The argument for it being like it is is that root is all powerfull so 
> they should be allowed to do anything. But the beauty of auid is that 
> it lets me see who the root sudoer really is.

But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and
admin does a restart of sshd, sshd will not be able to set it either. If you
only allow setting auid if its non-zero, how do you restart a service like
sshd since it will inherit the loginuid? The only option is to reboot the
machine, so forget about rpm upgrades.

I really think the answer is to protect this with SE Linux policy...but
there is a problem. I think that by setting loginuid by the proc filesystem
we won't be able to have a SE Linux type that is distinct for loginuid
without changing things in the kernel. Then you also have to worry about
descriptors being held open across forks. Not to mention, you have to do a
open(), write(), close() for each setting of loginuid.

So I think the best solution is to make a syscall for setting the loginuid
that SE Linux can protect with a distinct type. Then we can say things like
local_login_t is allowed setloginuid_t.

> (BTW - my 10$ says its should be a new capability since it doesn't 
> match either CONTROL or WRITE,

I've been saying that for a while too. I think it is distinct in the same
way that chown is different than unlink. Changing the loginuid is only 1
attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to
delete rules. So you change whether or not the event even was recorded as
opposed to who to blame.

But one thing that does help is deleting the rules is done via netlink
interface, which SE Linux does control. So, policy can be written that
disallows anything except auditctl_t from writing to netlink, and policy can
be written saying who can run auditctl.

-Steve

Re: (no subject)

[Steve Grubb]

On Friday 20 April 2007 20:24, paul moore wrote:
> A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why?

Show me an example.

> There is no error message

Not sure if '>' outputs error messages.

> B) always if I echo to /proc... as non root it is ignored (as it should be)
> but no message is generated; shouldn't it say EPERM?

Not sure the '>' outputs errors. You could strace it and see that the errno 
was returned and the shell did nothing with it.

> C) I put pam_loginuid in my gdm pam config but my xterm windows still have
> -1 in loginuid (I have rebooted)

How are you starting your xterm windows? If I use gnome terminal all is well. 
Even if I start an xterm window from it everything is still OK.

-Steve

(no subject)

[Kirkwood, David A.]

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

When I view the events related to xscreensaver for a locked screen  I
get 2 separate audit entries, one for a failure and 1 as a success. Both
have the same uid, euid, etc. Actually, the entries are exactly the same
except for the event number and the success outcome. I  have the
xscreensaver executable set -rwsr-xr-x. 

 

Thanks,

 

David A. Kirkwood



 


[-- Attachment #1.2: Type: text/html, Size: 2237 bytes --]

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

Re: (no subject)

[Bill Tangren]

Kirkwood, David A. wrote:
> When I view the events related to xscreensaver for a locked screen  I 
> get 2 separate audit entries, one for a failure and 1 as a success. Both 
> have the same uid, euid, etc. Actually, the entries are exactly the same 
> except for the event number and the success outcome. I  have the 
> xscreensaver executable set -rwsr-xr-x.
> 
>  
> 
>

The failure may be due to xscreensaver not being able to write to the faillog, 
if you are using pam_tally (to implement three strikes and you are locked out), 
but I'm just guessing.

(no subject)

[Kirkwood, David A]

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

I don't see any timestamps on audit events. How can I bracket events between
to dates /times?

 

 


[-- Attachment #1.2: Type: text/html, Size: 1610 bytes --]

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

Re: (no subject)

[Steve Grubb]

On Wednesday 03 May 2006 13:21, Kirkwood, David A wrote:
> I don't see any timestamps on audit events. How can I bracket events
> between to dates /times?

The ausearch utility was created to view the audit records. It extracts that 
information from the event. Can you give that a try?

ausearch -ts 1:00:00 -i

(This also assumes you have the audit daemon running.)

-Steve