Auditing failed kill events

Auditing failed kill events

[Henning, Arthur C. (CSL)]

RHEL kernel 2.6.18-8.el5xen

Audit 1.5.6-1.i386

Audit.rules entry:
-a entry,always -S kill

Attempt to kill a process which is not owned by that user. 
$ kill -9 nnnn
bash: kill: (nnnn) - Operation not permitted
$
Get log entry of the failed attempt 
# ausearch -i -sv no
type=SYSCALL msg=audit(08/21/2007 09:40:36.832:1458) : arch=i386
syscall=kill success=no exit=-1(Operation not permitted) a0=f8c a1=9
a2=f8c a3=f8c items=0 ppid=3391 pid=3402 auid=art uid=art gid=art
euid=art suid=art fsuid=art egid=art sgid=art fsgid=art tty=pts2
comm=bash exe=/bin/bash subj=user_u:system_r:unconfined_t:s0 key=(null) 

Is there a way to indentify the process which the user attempted to
kill? Or by whom the process is owned? The ppid and pid reported are
those of the user attempting to kill a process.

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

Re: Auditing failed kill events

[Steve Grubb]

On Tuesday 21 August 2007 11:13:35 Henning, Arthur C. (CSL) wrote:
> RHEL kernel 2.6.18-8.el5xen

This was the GA kernel which had an omission in several things for audit.

> Audit 1.5.6-1.i386

That's on RHEL?

> Get log entry of the failed attempt
> # ausearch -i -sv no
> type=SYSCALL msg=audit(08/21/2007 09:40:36.832:1458) : arch=i386
> syscall=kill success=no exit=-1(Operation not permitted) a0=f8c a1=9
> a2=f8c a3=f8c items=0 ppid=3391 pid=3402 auid=art uid=art gid=art
> euid=art suid=art fsuid=art egid=art sgid=art fsgid=art tty=pts2
> comm=bash exe=/bin/bash subj=user_u:system_r:unconfined_t:s0 key=(null)

You should have a OBJ_PID record, too.


> Is there a way to indentify the process which the user attempted to
> kill? 

Yes, the OBJ_PID record looks like this:

type=OBJ_PID msg=audit(08/21/2007 11:42:36.556:490) : opid=1709  
obj=system_u:system_r:auditd_t:s0 

> Or by whom the process is owned?

What is logged is the object ID that kill is acting upon. Which I suppose does 
not help in CAPP situations (and I don't think it was required by CAPP).

-Steve

RE: Auditing failed kill events

[Henning, Arthur C. (CSL)]

On Tuesday 21 August 2007 11:13:35 Henning, Arthur C. (CSL) wrote:
> RHEL kernel 2.6.18-8.el5xen

This was the GA kernel which had an omission in several things for
audit.

> Audit 1.5.6-1.i386

That's on RHEL? 
Art >> RHEL 5

> Get log entry of the failed attempt
> # ausearch -i -sv no
> type=SYSCALL msg=audit(08/21/2007 09:40:36.832:1458) : arch=i386
> syscall=kill success=no exit=-1(Operation not permitted) a0=f8c a1=9
> a2=f8c a3=f8c items=0 ppid=3391 pid=3402 auid=art uid=art gid=art
> euid=art suid=art fsuid=art egid=art sgid=art fsgid=art tty=pts2
> comm=bash exe=/bin/bash subj=user_u:system_r:unconfined_t:s0
key=(null)

You should have a OBJ_PID record, too.
Art >> Don't find it. I use ausearch -sv no > [filename]. Open the file
and find no OBJ_PID. Perhaps my rule isn't configured to allow this to
be captured.

> Is there a way to indentify the process which the user attempted to
> kill? 

Yes, the OBJ_PID record looks like this:

type=OBJ_PID msg=audit(08/21/2007 11:42:36.556:490) : opid=1709  
obj=system_u:system_r:auditd_t:s0 

> Or by whom the process is owned?

What is logged is the object ID that kill is acting upon. Which I
suppose does 
not help in CAPP situations (and I don't think it was required by CAPP).
Art >> This will be a NISPOM compliant machine. Perhaps not specifically
DSS required but supplemental as internal req's.
Art

-Steve

Re: Auditing failed kill events

[Steve Grubb]

On Tuesday 21 August 2007 13:50:24 Henning, Arthur C. (CSL) wrote:
> > Audit 1.5.6-1.i386
>
> That's on RHEL?
> Art >> RHEL 5

audit-1.5.5-7 is scheduled for RHEL5.  :)


> You should have a OBJ_PID record, too.
> Art >> Don't find it. I use ausearch -sv no > [filename]. Open the file
> and find no OBJ_PID. Perhaps my rule isn't configured to allow this to
> be captured.

You need a newer kernel. This was fixed in our LSPP work and will be in 5.1. 
You can find the LSPP kernels here:

ftp://ftp.redhat.com/pub/redhat/linux/eal/EAL4_RHEL5

But there have probably been some security releases since LSPP was final, so 
you'd want to switch to the 5.1 kernel as soon as its out. 

-Steve

RE: Auditing failed kill events

[Henning, Arthur C. (CSL)]

Is there way to FTP the needed LSPP files rather than downloading each
one individually?
Thanks,

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

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Tuesday, August 21, 2007 1:17 PM
To: Henning, Arthur C. (CSL)
Cc: linux-audit@redhat.com
Subject: Re: Auditing failed kill events

On Tuesday 21 August 2007 13:50:24 Henning, Arthur C. (CSL) wrote:
> > Audit 1.5.6-1.i386
>
> That's on RHEL?
> Art >> RHEL 5

audit-1.5.5-7 is scheduled for RHEL5.  :)


> You should have a OBJ_PID record, too.
> Art >> Don't find it. I use ausearch -sv no > [filename]. Open the
file
> and find no OBJ_PID. Perhaps my rule isn't configured to allow this to
> be captured.

You need a newer kernel. This was fixed in our LSPP work and will be in
5.1. 
You can find the LSPP kernels here:

ftp://ftp.redhat.com/pub/redhat/linux/eal/EAL4_RHEL5

But there have probably been some security releases since LSPP was
final, so 
you'd want to switch to the 5.1 kernel as soon as its out. 

-Steve

"Watch"ing a directory

[Pete Briggs]

Is there any way to put a watch on a directory, so that an audit record
will be generated if anyone cd's to that directory. I've tried things
like:

-w /etc/audit/ -k ACCESS_AUDIT

but the rule never seems to get invoked. I'm running FC7 with
audit-1.5.3

Thanks for any help
- Pete Briggs

Re: "Watch"ing a directory

[Steve Grubb]

On Wednesday 22 August 2007 10:17:37 Pete Briggs wrote:
> Is there any way to put a watch on a directory, 

Sort of...RHEL5.1 will have subtree auditing working in it. Al Viro also sent 
the patch upstream and should land in 2.6.23 or 24.

> so that an audit record will be generated if anyone cd's to that directory. 

Not for cd'ing into a directory. They have to attempt to read, write, change 
an attribute, or execute a file.

> I've tried things like:
>
> -w /etc/audit/ -k ACCESS_AUDIT

That is how you would watch a directory with current audit package and kernel 
with the subtree auditing patch.

> but the rule never seems to get invoked. I'm running FC7 with
> audit-1.5.3

They have to actually do something for it to trip...assuming you have a kernel 
that supports it.

-Steve

Re: "Watch"ing a directory

[Sankarshan Mukhopadhyay]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pete Briggs wrote:
> Is there any way to put a watch on a directory, so that an audit record
> will be generated if anyone cd's to that directory. I've tried things
> like:
> 
> -w /etc/audit/ -k ACCESS_AUDIT
> 
> but the rule never seems to get invoked. I'm running FC7 with
> audit-1.5.3

Let me add to this question ? Is it feasible to watch a top level
directory recursively ? ie say /opt and not /opt/mydir/mymoredir/ etc ?




- --

You see things; and you say 'Why?';
But I dream things that never were;
and I say 'Why not?' - George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGzErKXQZpNTcrCzMRAg3RAJ9x665sUBd5hzRjdX3x/g3bGdk6eACgpQn9
Wueth9+1jtrA+1S/za0qsgY=
=qowH
-----END PGP SIGNATURE-----

Re: "Watch"ing a directory

[Steve Grubb]

On Wednesday 22 August 2007 10:40:11 Sankarshan Mukhopadhyay wrote:
> Let me add to this question ? Is it feasible to watch a top level
> directory recursively ? ie say /opt and not /opt/mydir/mymoredir/ etc ?

Yes. Assuming you have the patched kernel and recent user space.

-Steve

Re: "Watch"ing a directory

[Eric Paris]

On Wed, 2007-08-22 at 10:59 -0400, Steve Grubb wrote:
> On Wednesday 22 August 2007 10:40:11 Sankarshan Mukhopadhyay wrote:
> > Let me add to this question ? Is it feasible to watch a top level
> > directory recursively ? ie say /opt and not /opt/mydir/mymoredir/ etc ?
> 
> Yes. Assuming you have the patched kernel and recent user space.

But not / itself.

RE: "Watch"ing a directory

[Ameel Kamboh]

Is that in the RHEL5 distribution?
Which versions of audit and kernel support recursive dir watch? 


Ameel Kamboh
SIP Core Network and Security 
Phone: 972.685.4922 (esn 445-4922)
Mobile: 978-590-2280
SIP: akamboh@techtrial.com
email: akamboh@nortel.com



-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: Wednesday, August 22, 2007 10:00 AM
To: Sankarshan Mukhopadhyay
Cc: linux-audit@redhat.com
Subject: Re: "Watch"ing a directory

On Wednesday 22 August 2007 10:40:11 Sankarshan Mukhopadhyay wrote:
> Let me add to this question ? Is it feasible to watch a top level 
> directory recursively ? ie say /opt and not /opt/mydir/mymoredir/ etc
?

Yes. Assuming you have the patched kernel and recent user space.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: "Watch"ing a directory

[Pete Briggs]

Once I tried something like touching a file, this worked as advertised,
I'm using kernel:

2.6.21-1.3194.fc7

on Fedora 7

Thanks again - Pete Briggs

On Wed, 2007-08-22 at 10:36 -0400, Steve Grubb wrote:
> On Wednesday 22 August 2007 10:17:37 Pete Briggs wrote:
> > Is there any way to put a watch on a directory, 
> 
> Sort of...RHEL5.1 will have subtree auditing working in it. Al Viro also sent 
> the patch upstream and should land in 2.6.23 or 24.
> 
> > so that an audit record will be generated if anyone cd's to that directory. 
> 
> Not for cd'ing into a directory. They have to attempt to read, write, change 
> an attribute, or execute a file.
> 
> > I've tried things like:
> >
> > -w /etc/audit/ -k ACCESS_AUDIT
> 
> That is how you would watch a directory with current audit package and kernel 
> with the subtree auditing patch.
> 
> > but the rule never seems to get invoked. I'm running FC7 with
> > audit-1.5.3
> 
> They have to actually do something for it to trip...assuming you have a kernel 
> that supports it.
> 
> -Steve
> 

Re: "Watch"ing a directory

[Steve Grubb]

On Wednesday 22 August 2007 11:40:00 Pete Briggs wrote:
> Once I tried something like touching a file, this worked as advertised,
> I'm using kernel:
>
> 2.6.21-1.3194.fc7
>
> on Fedora 7

Fedora 7 does not have the subtree auditing patch in it yet. This means that 
if you place a watch on a directory, it is watching the inode of the 
directory entries. So, this will work for 1 level. 

IOW a watch on /etc will let you see a change to /etc/passwd, but you will not 
see a change to /etc/ssh/ssh_config because its 2 levels down.

-Steve

Re: "Watch"ing a directory

[Steve Grubb]

On Wednesday 22 August 2007 11:05:07 Ameel Kamboh wrote:
> Is that in the RHEL5 distribution?

It will be in 5.1. You can already access it in the beta channel.

> Which versions of audit and kernel support recursive dir watch?


audit-1.5.5-6 and kernel-2.6.18-40.el5. Newer versions work even better. 

For Fedora, it will have to wait until either 2.6.23 or 24 depending on how 
fast the patch gets pulled into mainline. It was in -mm tree, though.

-Steve

RE: "Watch"ing a directory

[Ameel Kamboh]

 
For recursive watch can you exclude an inode from the watch list.

For example, I want a recursive watch on all directories and their sub
dir under /var
But would like to exclude /var/log specifically?

Ameel Kamboh
SIP Core Network and Security 
Phone: 972.685.4922 (esn 445-4922)
Mobile: 978-590-2280
SIP: akamboh@techtrial.com
email: akamboh@nortel.com



-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com] 
Sent: Wednesday, August 22, 2007 11:10 AM
To: Kamboh, Ameel (RICH1:B670)
Cc: Sankarshan Mukhopadhyay; linux-audit@redhat.com
Subject: Re: "Watch"ing a directory

On Wednesday 22 August 2007 11:05:07 Ameel Kamboh wrote:
> Is that in the RHEL5 distribution?

It will be in 5.1. You can already access it in the beta channel.

> Which versions of audit and kernel support recursive dir watch?


audit-1.5.5-6 and kernel-2.6.18-40.el5. Newer versions work even better.


For Fedora, it will have to wait until either 2.6.23 or 24 depending on
how fast the patch gets pulled into mainline. It was in -mm tree,
though.

-Steve

RE: "Watch"ing a directory

[Wieprecht, Karen M.]

We catch failures to cd into a directory with the rule "-a exit,always
-S all -F exit=-13"

Perhaps this captures too much, but it does seem to get the failed cd
attempts.  

Karen Wieprecht