10:13 a.m.
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(a)ngc.com
10:50 a.m.
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
12:50 p.m.
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
1:16 p.m.
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
4:19 p.m.
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(a)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(a)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
9:17 a.m.
New subject: "Watch"ing a directory
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
9:36 a.m.
New subject: "Watch"ing a directory
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
10:40 a.m.
New subject: "Watch"ing a directory
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
11:03 a.m.
New subject: "Watch"ing a directory
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
3:37 p.m.
New subject: "Watch"ing a directory
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
9:40 a.m.
New subject: "Watch"ing a directory
-----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-----
9:59 a.m.
New subject: "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
10:03 a.m.
New subject: "Watch"ing a directory
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.
10:05 a.m.
New subject: "Watch"ing a directory
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(a)techtrial.com
email: akamboh(a)nortel.com
-----Original Message-----
From: linux-audit-bounces(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
11:09 a.m.
New subject: "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
3:16 p.m.
New subject: "Watch"ing a directory
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(a)techtrial.com
email: akamboh(a)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(a)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
6331
days inactive
6332
days old
linux-audit@lists.linux-audit.osci.io
15 comments
7 participants
participants (7)
-
Ameel Kamboh -
Eric Paris -
Henning, Arthur C. (CSL) -
Pete Briggs -
Sankarshan Mukhopadhyay -
Steve Grubb -
Wieprecht, Karen M.