auditd stop suggestion
by Michael C Thompson
I was wondering, based on the amounts of sleeps we are needed to put into
our test cases (and this might already have been said, if so, keep the
flames to a low simmer) is there some way to change auditd stop to have it
capture all of the messages up until the point where the stop was issued?
Seems to me that while this change doesn't have to come now, it would be a
nice addition in the future. Perhaps having the auditd stop insert a
message into the queue (if thats possible?) and have auditd die when it
seems that message, as opposed to just dropping dead when the stop is made,
causing a possible (and highly probable, happens all the time with our
tests if they don't have sleeps) loss of information.
Thought I'd mention it if no one hasn't yet.
Mike
BTW, if this isn't in plaintext, let me know, until this point it has been.
20 years
linux-2.6.9-11.EL.audit.57 kernel
by David Woodhouse
Now that the RHEL4 U1 kernel is out, I've started using it as the base
for the audit kernel RPM.
* Tue Jun 14 2005 David Woodhouse <dwmw2(a)redhat.com> audit.57
- Merge selinux avc patches (#158957, #158968)
--
dwmw2
20 years
User space message bug
by Steve Grubb
Hello,
I was doing some testing and found that user space messages are sent without checking the audit_enabled flag:
[root@endeavor ~]# auditctl -e 0
AUDIT_STATUS: enabled=0 flag=1 pid=1701 rate_limit=0 backlog_limit=1024 lost=0 backlog=0
[root@endeavor ~]# auditctl -m "This is a test"
[root@endeavor ~]# ausearch -m USER
----
time->Tue Jun 14 10:48:43 2005
type=USER msg=audit(1118760523.312:13408080): user pid=24223 uid=0 auid=4294967295 msg='This is a test'
The following patch fixes it:
diff -ur linux-2.6.9.orig/kernel/audit.c linux-2.6.9/kernel/audit.c
--- linux-2.6.9.orig/kernel/audit.c 2005-06-14 10:50:16.000000000 -0400
+++ linux-2.6.9/kernel/audit.c 2005-06-14 10:53:05.000000000 -0400
@@ -444,6 +444,8 @@
break;
case AUDIT_USER:
case AUDIT_FIRST_USER_MSG...AUDIT_LAST_USER_MSG:
+ if (!audit_enabled)
+ break;
ab = audit_log_start(NULL, msg_type);
if (!ab)
break; /* audit_panic has been called */
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
20 years
Fwd: Audit / Netlink slowness
by Timothy R. Chavez
Passing this down the grape vine... This time forwarding and not replying
*cough*
-tim
---------- Forwarded Message ----------
Subject: Fwd: Audit / Netlink slowness
Date: Tuesday 14 June 2005 02:50
From: Jerone Young <jerone(a)gmail.com>
To: tinytim(a)us.ibm.com
---------- Forwarded message ----------
From: Bernardo Innocenti <bernie(a)develer.com>
Date: Jun 14, 2005 2:04 AM
Subject: Audit / Netlink slowness
To: fedora-devel-list(a)redhat.com
Hello,
on a server running kernel 2.6.11-1.1369_FC4, both ssh
and su where taking a longish amount of time (over >1.5 sec.)
Running "strace -r 2>strace.out su", I discovered that
netlink communication is the major cause of slowdown.
"su" connects to a NETLINK_AUDIT socket 3 or 4 times.
Each time it does 2 sendto() + recvfrom() operations,
with a latency of ~200ms. This adds up to 800ms wasted
time.
Disabling CONFIG_AUDIT in the kernel makes su and ssh
very fast again.
Is this behavior to be expected? CONFIG_AUDIT is enabled
by default, therefore many people are going to be hit by
this problem.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
-------------------------------------------------------
20 years
Re: Fwd: Audit / Netlink slowness
by Timothy R. Chavez
Just passing this down the grapevine...
-tim
On Tuesday 14 June 2005 02:50, Jerone Young wrote:
> ---------- Forwarded message ----------
> From: Bernardo Innocenti <bernie(a)develer.com>
> Date: Jun 14, 2005 2:04 AM
> Subject: Audit / Netlink slowness
> To: fedora-devel-list(a)redhat.com
>
>
> Hello,
>
> on a server running kernel 2.6.11-1.1369_FC4, both ssh
> and su where taking a longish amount of time (over >1.5 sec.)
>
> Running "strace -r 2>strace.out su", I discovered that
> netlink communication is the major cause of slowdown.
>
> "su" connects to a NETLINK_AUDIT socket 3 or 4 times.
> Each time it does 2 sendto() + recvfrom() operations,
> with a latency of ~200ms. This adds up to 800ms wasted
> time.
>
> Disabling CONFIG_AUDIT in the kernel makes su and ssh
> very fast again.
>
> Is this behavior to be expected? CONFIG_AUDIT is enabled
> by default, therefore many people are going to be hit by
> this problem.
>
> --
> // Bernardo Innocenti - Develer S.r.l., R&D dept.
> \X/ http://www.develer.com/
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
20 years
audit 0.9.4 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Rule and watch insert no longer automatically dumps list
- auditctl rules can now use auid in addition to loginuid
- Add sighup support for daemon reconfiguration
- Move some functions into private.h
This update represents that last feature (sighup) being added for the CAPP
development work. At this point, I think we are at a point where we need lots
of testing, bug reports, and review of man pages.
-Steve Grubb
20 years
audit.56 oops
by Rob Myers
here are 2 oopses with audit.56 with a few file watches enabled.
the second one happened when i was updating to audit 0.9.4. i don't
know what triggered the first.
rob.
[root@localhost ~]# auditctl -l
No rules
AUDIT_WATCH_LIST: dev=8:2, path=/etc/shadow, filterkey=fk_etc_shadow,
perms=rwea, valid=0
AUDIT_WATCH_LIST: dev=8:2, path=/etc/passwd, filterkey=fk_etc_passwd,
perms=rwea, valid=0
AUDIT_WATCH_LIST: dev=8:2, path=/etc/auditd.conf,
filterkey=fk_etc_auditd.conf, perms=rwea, valid=0
AUDIT_WATCH_LIST: dev=8:2, path=/etc/audit.rules,
filterkey=fk_etc_audit.rules, perms=rwea, valid=0
AUDIT_WATCH_LIST: dev=8:5, path=/var/log/audit,
filterkey=fk_var_log_audit, perms=rwe, valid=0
AUDIT_WATCH_LIST: dev=8:5, path=/var/log/messages,
filterkey=fk_var_log_messages, perms=rwe, valid=0
AUDIT_WATCH_LIST: dev=8:5, path=/var/log/messages-old,
filterkey=fk_var_log_messages-old, perms=rwea, valid=0
Jun 13 08:22:47 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Jun 13 08:22:47 localhost kernel: printing eip:
Jun 13 08:22:47 localhost kernel: c013cdd5
Jun 13 08:22:47 localhost kernel: *pde = 11651001
Jun 13 08:22:47 localhost kernel: Oops: 0002 [#1]
Jun 13 08:22:47 localhost kernel: SMP
Jun 13 08:22:47 localhost kernel: Modules linked in: i2c_dev i2c_core
ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod button
battery ac uhci_hcd ehci_hcd hw_random snd_intel8x0 snd_ac97_codec
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore sk98lin floppy
ext3 jbd i2o_block i2o_core ata_piix libata aic7xxx sd_mod scsi_mod
Jun 13 08:22:47 localhost kernel: CPU: 0
Jun 13 08:22:47 localhost kernel: EIP: 0060:[<c013cdd5>] Not
tainted VLI
Jun 13 08:22:47 localhost kernel: EFLAGS: 00010246
(2.6.9-5.0.3.EL.audit.56smp)
Jun 13 08:22:47 localhost kernel: EIP is at audit_inode_free+0xe6/0x113
Jun 13 08:22:47 localhost kernel: eax: d84b735c ebx: 00000000 ecx:
00000000 edx: d84b7370
Jun 13 08:22:47 localhost kernel: esi: ce96d770 edi: dc1ca180 ebp:
dfb58d5c esp: cb639ecc
Jun 13 08:22:47 localhost kernel: ds: 007b es: 007b ss: 0068
Jun 13 08:22:47 localhost kernel: Process usermod (pid: 3521,
threadinfo=cb639000 task=da0119b0)
Jun 13 08:22:47 localhost kernel: Stack: ce96d770 ce96d770 dc2fd93c
dfb58d5c c016c914 ce96d770 c016d952 dc2fd934
Jun 13 08:22:47 localhost kernel: c016b15b 00000000 dc2fd934
d822cdf4 c0165a6f 00000000 dfb58d5c c6ab2000
Jun 13 08:22:47 localhost kernel: c5d28000 dfb58d5c c15f2e00
ceb0fa2e 00000006 c6ab2005 00000010 00000000
Jun 13 08:22:47 localhost kernel: Call Trace:
Jun 13 08:22:47 localhost kernel: [<c016c914>] destroy_inode+0x1b/0x4c
Jun 13 08:22:47 localhost kernel: [<c016d952>] iput+0x5f/0x61
Jun 13 08:22:47 localhost kernel: [<c016b15b>] dput+0x17b/0x1a7
Jun 13 08:22:47 localhost kernel: [<c0165a6f>] sys_rename+0x157/0x1e0
Jun 13 08:22:47 localhost kernel: [<c0109ebb>] do_syscall_trace
+0xc0/0xc9
Jun 13 08:22:47 localhost kernel: [<c02c82db>] syscall_call+0x7/0xb
Jun 13 08:22:47 localhost kernel: Code: 89 d8 e8 5d f4 ff ff 89 d8 e8 56
f4 ff ff e8 04 f1 ff ff 89 ea e9 5e ff ff ff 8b 57 0c 85 d2 74 27 8b 1a
8d 42 ec 8b 4a 04 85 db <89> 19 74 03 89 4b 04 c7 02 00 01 10 00 c7 42
04 00 02 20 00 e8
Jun 13 12:56:36 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Jun 13 12:56:36 localhost kernel: printing eip:
Jun 13 12:56:36 localhost kernel: c013cdd5
Jun 13 12:56:36 localhost kernel: *pde = 0f408001
Jun 13 12:56:36 localhost kernel: Oops: 0002 [#1]
Jun 13 12:56:36 localhost kernel: SMP
Jun 13 12:56:36 localhost kernel: Modules linked in: i2c_dev i2c_core
ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod button
battery ac uhci_hcd ehci_hcd hw_random snd_intel8x0 snd_ac97_codec
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore sk98lin floppy
ext3 jbd i2o_block i2o_core ata_piix libata aic7xxx sd_mod scsi_mod
Jun 13 12:56:36 localhost kernel: CPU: 0
Jun 13 12:56:36 localhost kernel: EIP: 0060:[<c013cdd5>] Not
tainted VLI
Jun 13 12:56:36 localhost kernel: EFLAGS: 00010246
(2.6.9-5.0.3.EL.audit.56smp)
Jun 13 12:56:36 localhost kernel: EIP is at audit_inode_free+0xe6/0x113
Jun 13 12:56:36 localhost kernel: eax: d7f4e32c ebx: 00000000 ecx:
00000000 edx: d7f4e340
Jun 13 12:56:36 localhost kernel: esi: da7b6548 edi: de03cd60 ebp:
df8f42ac esp: c5dd6ecc
Jun 13 12:56:36 localhost kernel: ds: 007b es: 007b ss: 0068
Jun 13 12:56:36 localhost kernel: Process rpm (pid: 9601,
threadinfo=c5dd6000 task=ce6fa230)
Jun 13 12:56:36 localhost kernel: Stack: da7b6548 da7b6548 dd155b04
df8f42ac c016c914 da7b6548 c016d952 dd155afc
Jun 13 12:56:36 localhost kernel: c016b15b 00000000 dd155afc
c588b50c c0165a6f 00000000 df8f42ac c641f000
Jun 13 12:56:36 localhost kernel: c6c0b000 df8f42ac c15f2e00
2cefc80a 0000000b c641f005 00000010 00000000
Jun 13 12:56:36 localhost kernel: Call Trace:
Jun 13 12:56:36 localhost kernel: [<c016c914>] destroy_inode+0x1b/0x4c
Jun 13 12:56:36 localhost kernel: [<c016d952>] iput+0x5f/0x61
Jun 13 12:56:36 localhost kernel: [<c016b15b>] dput+0x17b/0x1a7
Jun 13 12:56:36 localhost kernel: [<c0165a6f>] sys_rename+0x157/0x1e0
Jun 13 12:56:36 localhost kernel: [<c01077ff>] do_IRQ+0xd5/0x130
Jun 13 12:56:36 localhost kernel: [<c0107822>] do_IRQ+0xf8/0x130
Jun 13 12:56:36 localhost kernel: [<c02c8c98>] common_interrupt
+0x18/0x20
Jun 13 12:56:36 localhost kernel: [<c0109ebb>] do_syscall_trace
+0xc0/0xc9
Jun 13 12:56:36 localhost kernel: [<c02c82db>] syscall_call+0x7/0xb
Jun 13 12:56:36 localhost kernel: Code: 89 d8 e8 5d f4 ff ff 89 d8 e8 56
f4 ff ff e8 04 f1 ff ff 89 ea e9 5e ff ff ff 8b 57 0c 85 d2 74 27 8b 1a
8d 42 ec 8b 4a 04 85 db <89> 19 74 03 89 4b 04 c7 02 00 01 10 00 c7 42
04 00 02 20 00 e8
20 years
Unable to login
by James Morris
I'm unable to login to current rawhide and the 2.6.12-rc6 kernel, with
auditd enabled.
I think these audit.log messages are the cause:
type=KERNEL msg=audit(1118503063.368:248607): SELinux: unrecognized
netlink message type=1100 for sclass=49
type=KERNEL msg=audit(1118503063.368:248607): syscall=102 arch=40000003
success=no exit=-22 a0=b a1=bfc3ab10 a2=7150f8 a3=66 items=0
pid=1916 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm=login exe=/bin/login
No diagnostics are displayed on the console though.
Can auditd translate Unix epochs into human readable timestamps?
- James
--
James Morris
<jmorris(a)redhat.com>
20 years
audit.56 merged with audit-2.6.git
by Timothy R. Chavez
Alright,
I merged all the changes in audit.56 that were not in audit-2.6.git for the LKML RFC.
If you could please look over this and maybe even build and test a little to make sure
it works, that'd be good! I did a little testing and things seem to be in good order,
but it doesn't hurt to have an extra set of eyes and what-not.
There is a problem that hasn't been worked out yet that is preventing us from adding a
large number of watches... it bombs at around ~360 insertions IF we're triggering those
watches (adding watches, touching the watch file), but works perfectly fine when we
simply add them without triggering them.
There are still some other things that need to be done, minor things, with regards to
auditfs (like logging when implicit watch removals occur), but other then that I think
David and I feel this is probably ready for an LKML RFC.
Should I remove all parts of this patch that do not pertain to auditfs? Should we
push Chris's netlink work to the git tree and then patch against that for RFC?
-tim
20 years
