9:26 a.m.
Uploading now...
* Wed May 25 2005 David Woodhouse <dwmw2(a)redhat.com> audit.49
- Clean up logging of untrusted strings in avc.c (Stephen Smalley)
- auditfs update (Tim Chavez)
--
dwmw2
11:01 a.m.
On Wednesday 25 May 2005 10:26, David Woodhouse wrote:
- auditfs update (Tim Chavez)
This kernel survived inserting rules better. However, it got into a state
where I couldn't insert rules anymore. I couldn't delete them either. I got
the "no such path" error message. So I decided to reboot and see how to
reproduce it. On shutdown, it spewed these messages:
May 25 11:48:22 localhost kernel: audit(1117036102.346:3047572): watch=""
filterkey=fk_passwd perm=15 perm_mask=4 inode=214331 inode_uid=0 inode_gid=0
inode_dev=03:02 inode_rdev=00:00
May 25 11:48:22 localhost kernel: audit(1117036102.346:3047572): item=0
name="/etc/passwd" inode=214331 dev=03:02 mode=0100644 ouid=0 ogid=0
rdev=00:00
Then I got a kernel panic. I wrote these down by hand so its not complete:
EIP 0060
EIP is at audit_update_watch+0x17d/0x2bc
Process mount (pid:4580
Call trace:
shrink_dcache_sb
do_remount_sb
do_remount
__alloc_pages
sys_mount
Kernel panic - not syncing lib/dec_and_lock.c:32
spinlock(fs/dcache.c:c0352ee0) already locked by fs/dcache.c/377
I'll try to work out the recipe to reproduce this failure.
-Steve
11:34 a.m.
On Wednesday 25 May 2005 11:01, Steve Grubb wrote:
On Wednesday 25 May 2005 10:26, David Woodhouse wrote:
> - auditfs update (Tim Chavez)
This kernel survived inserting rules better. However, it got into a state
where I couldn't insert rules anymore. I couldn't delete them either. I got
the "no such path" error message. So I decided to reboot and see how to
reproduce it. On shutdown, it spewed these messages:
May 25 11:48:22 localhost kernel: audit(1117036102.346:3047572): watch=""
filterkey=fk_passwd perm=15 perm_mask=4 inode=214331 inode_uid=0 inode_gid=0
inode_dev=03:02 inode_rdev=00:00
May 25 11:48:22 localhost kernel: audit(1117036102.346:3047572): item=0
name="/etc/passwd" inode=214331 dev=03:02 mode=0100644 ouid=0 ogid=0
rdev=00:00
Then I got a kernel panic. I wrote these down by hand so its not complete:
EIP 0060
EIP is at audit_update_watch+0x17d/0x2bc
Process mount (pid:4580
Call trace:
shrink_dcache_sb
do_remount_sb
do_remount
__alloc_pages
sys_mount
Kernel panic - not syncing lib/dec_and_lock.c:32
spinlock(fs/dcache.c:c0352ee0) already locked by fs/dcache.c/377
Schnikies. That's awfully suspicious. I'll look into this after lunch
-tim
I'll try to work out the recipe to reproduce this failure.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
12:29 p.m.
On Wednesday 25 May 2005 12:34, Timothy R. Chavez wrote:
Schnikies. That's awfully suspicious. I'll look into this
after lunch
Try this script with audit-0.9:
#!/bin/bash
while [ 1 ] ;
do
echo "Inserting..."
auditctl -w /etc/passwd -k fk_passwd -p rwea
auditctl -w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
echo "Deleting..."
auditctl -D
done
Let it run in one window, check it after a few minutes. I always see stuff
like this:
[root@endeavor ~]# auditctl -l
AUDIT_LIST: entry always syscall=mkdir AUDIT_LIST: entry always syscall=kill
AUDIT_WATCH_LIST: dev=3:2, path=, filterkey=fk_passwd, perms=rwea, valid=0
[root@endeavor ~]# auditctl -D
Error sending list request (No such file or directory)
NLMSG_ERROR 2 (No such file or directory) type=2 seq=5
No watches
AUDIT_WATCH_LIST: dev=3:2, path=, filterkey=fk_passwd, perms=rwea, valid=0
Another...
[root@endeavor ~]# auditctl -l
No rules
AUDIT_WATCH_LIST: dev=3:2, path=, filterkey=fk_passwd, perms=rwea, valid=0
The common issue is that path= is empty???
This also deadlocked my computer once and I had to hit the reset button. No
oops. The mouse & keys did not work.
-Steve
12:48 p.m.
On Wednesday 25 May 2005 13:29, Steve Grubb wrote:
Try this script with audit-0.9:
This didn't take long...
May 25 13:35:27 localhost kernel: Unable to handle kernel paging request at virtual
address 705f6b6a
May 25 13:35:27 localhost kernel: printing eip:
May 25 13:35:27 localhost kernel: c014bac9
May 25 13:35:27 localhost kernel: *pde = 00000000
May 25 13:35:27 localhost kernel: Oops: 0002 [#1]
May 25 13:35:27 localhost kernel: Modules linked in: parport_pc lp parport autofs4 i2c_dev
i2c_core ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod button battery
ac md5 ipv6 uhci_hcd snd_emu10k1 snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm snd_timer
snd_seq_device snd_ac97_codec snd_page_alloc snd_util_mem snd_hwdep snd soundcore 3c59x
floppy ext3 jbd
May 25 13:35:27 localhost kernel: CPU: 0
May 25 13:35:27 localhost kernel: EIP: 0060:[<c014bac9>] Not tainted VLI
May 25 13:35:27 localhost kernel: EFLAGS: 00210006 (2.6.9-5.0.3.EL.audit.49)
May 25 13:35:27 localhost kernel: EIP is at cache_alloc_refill+0x146/0x227
May 25 13:35:27 localhost kernel: eax: 705f6b66 ebx: effefba0 ecx: dc974400 edx:
effefbbc
May 25 13:35:27 localhost kernel: esi: 00000002 edi: effefbac ebp: effe30a0 esp:
e5410dd0
May 25 13:35:27 localhost kernel: ds: 007b es: 007b ss: 0068
May 25 13:35:27 localhost kernel: Process metacity (pid: 2598, threadinfo=e5410000
task=e5458660)
May 25 13:35:27 localhost kernel: Stack: 000000d0 effefba0 000000d0 00200246 000000d0
c014c0af ef862880 00001f00
May 25 13:35:27 localhost kernel: e5a64dc0 c02a2971 00000000 00001eb4 ffffffe0
e5a64dc0 00000000 c02a1c31
May 25 13:35:27 localhost kernel: 00001eb4 00001eb4 00001eb4 e5a64b80 e5410e64
e4eb9980 c02a1d98 00000040
May 25 13:35:27 localhost kernel: Call Trace:
May 25 13:35:27 localhost kernel: [<c014c0af>] __kmalloc+0x6b/0x7d
May 25 13:35:27 localhost kernel: [<c02a2971>] alloc_skb+0x33/0xc5
May 25 13:35:27 localhost kernel: [<c02a1c31>] sock_alloc_send_pskb+0x5d/0x1b8
May 25 13:35:27 localhost kernel: [<c02a1d98>] sock_alloc_send_skb+0xc/0xf
May 25 13:35:27 localhost kernel: [<c02fcbdd>] unix_stream_sendmsg+0x14b/0x307
May 25 13:35:27 localhost kernel: [<c029f265>] sock_aio_write+0x106/0x113
May 25 13:35:27 localhost kernel: [<c0163bc9>] do_sync_write+0x97/0xc9
May 25 13:35:27 localhost kernel: [<c01c3afd>] selinux_file_permission+0x114/0x11d
May 25 13:35:27 localhost kernel: [<c011d04b>] autoremove_wake_function+0x0/0x2d
May 25 13:35:27 localhost kernel: [<c01413c5>] audit_syscall_entry+0x125/0x13e
May 25 13:35:27 localhost kernel: [<c0163cc1>] vfs_write+0xc6/0xe2
May 25 13:35:27 localhost kernel: [<c0163d7b>] sys_write+0x3c/0x62
May 25 13:35:27 localhost kernel: [<c0303707>] syscall_call+0x7/0xb
May 25 13:35:27 localhost kernel: Code: af 43 34 03 41 0c 89 44 95 10 ff 45 00 8b 51 10 0f
b7 41 14 42 89 51 10 0f b7 44 41 18 66 89 41 14 3b 53 3c 72 cc 8b 51 04 8b 01 <89>
50 04 89 02 66 83 79 14 ff c7 01 00 01 10 00 c7 41 04 00 02
Then I loaded kernel-debuginfo & started gdb.
(gdb) list *0xc014bac9
0xc014bac9 is in cache_alloc_refill (include/linux/list.h:151).
146 include/linux/list.h: No such file or directory.
in include/linux/list.h
-Steve
2:33 p.m.
On Wednesday 25 May 2005 12:29, Steve Grubb wrote:
On Wednesday 25 May 2005 12:34, Timothy R. Chavez wrote:
> Schnikies. That's awfully suspicious. I'll look into this after lunch
Try this script with audit-0.9:
#!/bin/bash
while [ 1 ] ;
do
echo "Inserting..."
auditctl -w /etc/passwd -k fk_passwd -p rwea
auditctl -w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
echo "Deleting..."
auditctl -D
done
Just a quick update. I've let this run for 5 minutes on x86_64 (UP) using
audit-0.9 and will be attempting SMP momentarily. Still, the problems
you're getting are quite unnatural. I've been given some others machines
to test on and will do so promptly... I'm having a hard time figuring out
what this problem could be...
David did bring up a good point about me allocating memory in
audit_notify_watch(), but not handling it, should -ENOMEM be
returned (yikes), but I'm not sure this is related to what you're
seeing right now.
The common issue is that path= is empty???
I'm not sure how this could happen... I'm thinking it has to do with sending
information back to user space. I also saw that audit_update_watch() crapped
out on yah too. So these are the two places I'm focusing my attention.
This also deadlocked my computer once and I had to hit the reset button. No
oops. The mouse & keys did not work.
Yeah seems like there are two locking issues. One locking issue where a spinlock
that's held is trying to be held within it and the true deadlock.... ah locking
*cough*
-tim
2:39 p.m.
On Wednesday 25 May 2005 14:33, Timothy R. Chavez wrote:
On Wednesday 25 May 2005 12:29, Steve Grubb wrote:
> On Wednesday 25 May 2005 12:34, Timothy R. Chavez wrote:
> > Schnikies. That's awfully suspicious. I'll look into this after
lunch
>
> Try this script with audit-0.9:
>
> #!/bin/bash
> while [ 1 ] ;
> do
> echo "Inserting..."
> auditctl -w /etc/passwd -k fk_passwd -p rwea
> auditctl -w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
> echo "Deleting..."
> auditctl -D
> done
Just a quick update. I've let this run for 5 minutes on x86_64 (UP) using
audit-0.9
Without problems, I should mention.
-tim
2:42 p.m.
On Wednesday 25 May 2005 14:39, Timothy R. Chavez wrote:
On Wednesday 25 May 2005 14:33, Timothy R. Chavez wrote:
> On Wednesday 25 May 2005 12:29, Steve Grubb wrote:
> > On Wednesday 25 May 2005 12:34, Timothy R. Chavez wrote:
> > > Schnikies. That's awfully suspicious. I'll look into this after
lunch
> >
> > Try this script with audit-0.9:
> >
> > #!/bin/bash
> > while [ 1 ] ;
> > do
> > echo "Inserting..."
> > auditctl -w /etc/passwd -k fk_passwd -p rwea
> > auditctl -w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
> > echo "Deleting..."
> > auditctl -D
> > done
>
> Just a quick update. I've let this run for 5 minutes on x86_64 (UP) using
> audit-0.9
Without problems, I should mention.
-tim
*cough*
hlist_for_each_entry_safe(entry, pos, tmp, &skb_list, list) {
audit_send_reply(pid, seq, AUDIT_WATCH_LIST, 0, 1,
entry->memblk, entry->size);
---------------> ?????
kfree(entry->memblk);
kfree(entry);
}
audit_send_reply(pid, seq, AUDIT_WATCH_LIST, 1, 1, NULL, 0);
goto audit_list_watches_exit;
audit_list_watches_fail:
hlist_for_each_entry_safe(entry, pos, tmp, &skb_list, list) {
---------------> ?????
kfree(entry->memblk);
kfree(entry);
}
audit_list_watches_exit:
return ret;
}
Maybe I should be _deleting_ the hlist entries before I free the memory ;-)
*cough*
-tim
8:34 p.m.
I've made some changes... some of which I've talked about today and did a
little testing of my own. I'll post a patch to audit.49 tommorrow morning
after I do a little more testing.
Things that I did:
Split up audit_notify_watch() like David
Added error handling to audit_notify_watch()
Fixed some rogue spaces in audit_create_wentry() and audit_destroy_wentry()
Added hlist_del's to audit_list_watches()
I'm still unsure about what's causing all of Steve's problems... I'm still
trying to figure out the audit_update_watch() bomb
Thanks
-tim
7150
days inactive
7151
days old
linux-audit@lists.linux-audit.osci.io
9 comments
3 participants
participants (3)
-
David Woodhouse -
Steve Grubb -
Timothy R. Chavez