12:22 p.m.
I was trying out a syscall entry rule that I thought would block audit
records from system services/daemons that haven't had their audit ID
(auid) set yet. I've tried both:
-a entry,never -S all -F auid=-1
AND
-a entry,never -S all -F auid=4294967295
(4294967295) is the value that shows up in the audit log for these
services. I would have thought this rule was saying that at syscall
entry (for any system call), don't generate an audit event if the auid
is -1 or 4294967295. It seems to have the opposite effect. Have I
missed something? Is this rule not saying what I want?
--Tad Taylor
3:39 p.m.
On Thursday 12 July 2007 01:22:35 pm Taylor_Tad(a)emc.com wrote:
I was trying out a syscall entry rule that I thought would block
audit
records from system services/daemons that haven't had their audit ID
(auid) set yet.
Which kernel are you using? There was a signed/unsigned promotion and
comparison bug fixed not too long ago.
-Steve
7:18 a.m.
It's pretty much a stock RHEL 4.4 system.
{marge.rtp.dg.com}_5: rpm -q kernel audit audit-libs
kernel-2.6.9-42.EL
audit-1.0.14-1.EL4
audit-libs-1.0.14-1.EL4
{marge.rtp.dg.com}_6:
So, is the general idea behind the rules sound? You should be able to
block audit records for unset auids?
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, July 12, 2007 4:39 PM
To: linux-audit(a)redhat.com
Cc: Taylor, Tad
Subject: Re: Why doesn't this rule block syscall records?
On Thursday 12 July 2007 01:22:35 pm Taylor_Tad(a)emc.com wrote:
I was trying out a syscall entry rule that I thought would block
audit
records from system services/daemons that haven't had their audit
ID
(auid) set yet.
Which kernel are you using? There was a signed/unsigned promotion and
comparison bug fixed not too long ago.
-Steve
8:03 a.m.
While working on parsing the ausearch output on RHEL 4 update 4 and
RHEL4 update 5, I've noticed that there are some records generated that
have auid of unset/unknown (depending on which version of
auditd/ausearch you are using) that you may not wish to blindly ignore.
For instance, an ssh login goes through some pam checks, and even
though the auid is unset/unknown, you can still discern who was trying
to log in and which pam check failed from elsewhere in the record,
something you may or may not wish to see when reviewing your logs.
I think I've seen similar things when users log in at the console, but
I'd have to double check.
Another important place I see records with auid unset/unknown when an
already-logged-in user initiates an "su". I've been able to determine
the actual auid and effective UID (who the person was trying to become
via "su") from other things in the audit record, but this is another
case where you may not want to simply ignore records that have auid
unset/unknown.
Food for thought,
Karen Wieprecht
-----Original Message-----
From: linux-audit-bounces(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Taylor_Tad(a)emc.com
Sent: Friday, July 13, 2007 8:19 AM
To: sgrubb(a)redhat.com; linux-audit(a)redhat.com
Subject: RE: Why doesn't this rule block syscall records?
It's pretty much a stock RHEL 4.4 system.
{marge.rtp.dg.com}_5: rpm -q kernel audit audit-libs
kernel-2.6.9-42.EL
audit-1.0.14-1.EL4
audit-libs-1.0.14-1.EL4
{marge.rtp.dg.com}_6:
So, is the general idea behind the rules sound? You should be able to
block audit records for unset auids?
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Thursday, July 12, 2007 4:39 PM
To: linux-audit(a)redhat.com
Cc: Taylor, Tad
Subject: Re: Why doesn't this rule block syscall records?
On Thursday 12 July 2007 01:22:35 pm Taylor_Tad(a)emc.com wrote:
I was trying out a syscall entry rule that I thought would block
audit
records from system services/daemons that haven't had their audit
ID
(auid) set yet.
Which kernel are you using? There was a signed/unsigned promotion and
comparison bug fixed not too long ago.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
8:26 a.m.
On Friday 13 July 2007 08:18:57 am Taylor_Tad(a)emc.com wrote:
{marge.rtp.dg.com}_5: rpm -q kernel audit audit-libs
kernel-2.6.9-42.EL
OK, had to double check this. I think you are OK because the miscompare was bz
196233 which appears to have been fixed in -42. The current release, though,
is -55 which has another important audit fix in it. The rule comparison is
done by the kernel, so that is what matters. But also note that you could
have several kernels on a machine, so "uname -r" rather than "rpm -q
kernel"
is more appropriate.
So, is the general idea behind the rules sound?
Yes.
You should be able to block audit records for unset auids?
Yes. I think the long unsigned number is what you want to pass. Also, this
rule has to be the first one sent after deleting all rules in the audit.rules
file. This is because the audit system does "first match wins" top down order
when evaluating the rules.
-Steve
8:28 a.m.
On Friday 13 July 2007 09:26:48 am Steve Grubb wrote:
OK, had to double check this. I think you are OK because the
miscompare was
bz 196233 which appears to have been fixed in -42. The current release,
though, is -55 which has another important audit fix in it. The rule
comparison is done by the kernel, so that is what matters.
Sorry, re-reading bz, it was fixed in U5. Please try that kernel.
-Steve
12:42 p.m.
On Fri, 2007-07-13 at 09:28 -0400, Steve Grubb wrote:
On Friday 13 July 2007 09:26:48 am Steve Grubb wrote:
> OK, had to double check this. I think you are OK because the miscompare was
> bz 196233 which appears to have been fixed in -42. The current release,
> though, is -55 which has another important audit fix in it. The rule
> comparison is done by the kernel, so that is what matters.
Sorry, re-reading bz, it was fixed in U5. Please try that kernel.
As I recall it also was only an issue on non-32bit systems (x86_64,
ppc64, ia64, etc etc) So if this is a plain old i686 system, this isn't
your problem, if it is x86_64, steve probable nailed your problem right
on the head.
-Eric
6417
days inactive
6418
days old
linux-audit@lists.linux-audit.osci.io
6 comments
4 participants
participants (4)
-
Eric Paris -
Steve Grubb -
Taylor_Tad＠emc.com -
Wieprecht, Karen M.