10:58 a.m.
Hello,
I was testing file system auditing (kernel .46) and got the following when
removing a watch. First symptom was blinking keyboard lights.
-Steve
May 24 11:49:09 localhost kernel: kernel BUG at mm/slab.c:2787!
May 24 11:49:09 localhost kernel: invalid operand: 0000 [#1]
May 24 11:49:09 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 24 11:49:09 localhost kernel: CPU: 0
May 24 11:49:09 localhost kernel: EIP: 0060:[<c014c67f>] Not tainted VLI
May 24 11:49:09 localhost kernel: EFLAGS: 00010002
(2.6.9-5.0.3.EL.audit.46.sg.2)
May 24 11:49:09 localhost kernel: EIP is at cache_reap+0x111/0x273
May 24 11:49:09 localhost kernel: eax: effefa7c ebx: effefa60 ecx:
e612c180 edx: 0000003d
May 24 11:49:09 localhost kernel: esi: effefae8 edi: 00000001 ebp:
c03feae0 esp: eff18f5c
May 24 11:49:09 localhost kernel: ds: 007b es: 007b ss: 0068
May 24 11:49:09 localhost kernel: Process events/0 (pid: 3,
threadinfo=eff18000 task=efe20bd0)
May 24 11:49:09 localhost kernel: Stack: c03feb20 c03feb20 00000283 00000000
c16ff160 c01321a4 c014c56e ffffffff
May 24 11:49:09 localhost kernel: ffffffff 00000001 00000000 c011b9f2
00010000 00000000 efe20bd0 eff18fcc
May 24 11:49:09 localhost kernel: c0301651 00000000 efe20bd0 c011b9f2
00100100 00200200 00000004 efe20bd0
May 24 11:49:09 localhost kernel: Call Trace:
May 24 11:49:09 localhost kernel: [<c01321a4>] worker_thread+0x1eb/0x2f0
May 24 11:49:09 localhost kernel: [<c014c56e>] cache_reap+0x0/0x273
May 24 11:49:09 localhost kernel: [<c011b9f2>] default_wake_function+0x0/0xc
May 24 11:49:09 localhost kernel: [<c0301651>] schedule+0x431/0x544
May 24 11:49:09 localhost kernel: [<c011b9f2>] default_wake_function+0x0/0xc
May 24 11:49:09 localhost kernel: [<c0131fb9>] worker_thread+0x0/0x2f0
May 24 11:49:09 localhost kernel: [<c0136f81>] kthread+0x69/0x91
May 24 11:49:09 localhost kernel: [<c0136f18>] kthread+0x0/0x91
May 24 11:49:09 localhost kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb
May 24 11:49:09 localhost kernel: Code: e9 05 01 00 00 6b 4b 3c 05 8b 53 40 01
ca 4a 89 d0 31 d2 f7 f1 89 c7 8b 4b 1c 8d 43 1c 39 c1 0f 84 e5 00 00 00 83 79
10 00 74 08 <0f> 0b e3 0a 97 43 31 c0 8b 01 8b 51 04 89 50 04 89 02 c7 41 04
12:46 p.m.
On Tuesday 24 May 2005 10:58, Steve Grubb wrote:
Hello,
I was testing file system auditing (kernel .46) and got the following when
removing a watch. First symptom was blinking keyboard lights.
-Steve
Looks like I'm not putting a reference back when I should be.. somewhere.
Argh
-tim
May 24 11:49:09 localhost kernel: kernel BUG at mm/slab.c:2787!
May 24 11:49:09 localhost kernel: invalid operand: 0000 [#1]
May 24 11:49:09 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 24 11:49:09 localhost kernel: CPU: 0
May 24 11:49:09 localhost kernel: EIP: 0060:[<c014c67f>] Not tainted VLI
May 24 11:49:09 localhost kernel: EFLAGS: 00010002
(2.6.9-5.0.3.EL.audit.46.sg.2)
May 24 11:49:09 localhost kernel: EIP is at cache_reap+0x111/0x273
May 24 11:49:09 localhost kernel: eax: effefa7c ebx: effefa60 ecx:
e612c180 edx: 0000003d
May 24 11:49:09 localhost kernel: esi: effefae8 edi: 00000001 ebp:
c03feae0 esp: eff18f5c
May 24 11:49:09 localhost kernel: ds: 007b es: 007b ss: 0068
May 24 11:49:09 localhost kernel: Process events/0 (pid: 3,
threadinfo=eff18000 task=efe20bd0)
May 24 11:49:09 localhost kernel: Stack: c03feb20 c03feb20 00000283 00000000
c16ff160 c01321a4 c014c56e ffffffff
May 24 11:49:09 localhost kernel: ffffffff 00000001 00000000 c011b9f2
00010000 00000000 efe20bd0 eff18fcc
May 24 11:49:09 localhost kernel: c0301651 00000000 efe20bd0 c011b9f2
00100100 00200200 00000004 efe20bd0
May 24 11:49:09 localhost kernel: Call Trace:
May 24 11:49:09 localhost kernel: [<c01321a4>] worker_thread+0x1eb/0x2f0
May 24 11:49:09 localhost kernel: [<c014c56e>] cache_reap+0x0/0x273
May 24 11:49:09 localhost kernel: [<c011b9f2>] default_wake_function+0x0/0xc
May 24 11:49:09 localhost kernel: [<c0301651>] schedule+0x431/0x544
May 24 11:49:09 localhost kernel: [<c011b9f2>] default_wake_function+0x0/0xc
May 24 11:49:09 localhost kernel: [<c0131fb9>] worker_thread+0x0/0x2f0
May 24 11:49:09 localhost kernel: [<c0136f81>] kthread+0x69/0x91
May 24 11:49:09 localhost kernel: [<c0136f18>] kthread+0x0/0x91
May 24 11:49:09 localhost kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb
May 24 11:49:09 localhost kernel: Code: e9 05 01 00 00 6b 4b 3c 05 8b 53 40 01
ca 4a 89 d0 31 d2 f7 f1 89 c7 8b 4b 1c 8d 43 1c 39 c1 0f 84 e5 00 00 00 83 79
10 00 74 08 <0f> 0b e3 0a 97 43 31 c0 8b 01 8b 51 04 89 50 04 89 02 c7 41 04
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
-tim
2:19 p.m.
On Tuesday 24 May 2005 14:06, Timothy R. Chavez wrote:
Can you also provide architecture, UP/SMP, etc
I just upgraded to the .48 kernel and did this:
-a entry,always -S mkdir
-a entry,always -S kill
-w /etc/passwd -k fk_passwd -p rwea
-w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
This kills the machine dead...well except for the blinking numlock & caps lock
lights.
May 24 15:12:07 localhost kernel: kernel BUG at mm/slab.c:2787!
May 24 15:12:07 localhost kernel: invalid operand: 0000 [#1]
May 24 15:12:07 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 24 15:12:07 localhost kernel: CPU: 0
May 24 15:12:07 localhost kernel: EIP: 0060:[<c014c5f3>] Not tainted VLI
May 24 15:12:07 localhost kernel: EFLAGS: 00010086 (2.6.9-5.0.3.EL.audit.48)
May 24 15:12:07 localhost kernel: EIP is at cache_reap+0x111/0x273
May 24 15:12:07 localhost kernel: eax: effefbbc ebx: effefba0 ecx:
effefb00 edx: 00000034
May 24 15:12:07 localhost kernel: esi: effefc28 edi: 00000001 ebp:
c03feae0 esp: eff18f5c
May 24 15:12:07 localhost kernel: ds: 007b es: 007b ss: 0068
May 24 15:12:07 localhost kernel: Process events/0 (pid: 3,
threadinfo=eff18000 task=efe20bd0)
May 24 15:12:07 localhost kernel: Stack: c03feb20 c03feb20 00000283 00000000
c16ff160 c01321a4 c014c4e2 ffffffff
May 24 15:12:07 localhost kernel: ffffffff 00000001 00000000 c011b9f2
00010000 00000000 efe20bd0 eff18fcc
May 24 15:12:07 localhost kernel: c03015c9 00000000 efe20bd0 c011b9f2
00100100 00200200 00000004 efe20bd0
May 24 15:12:07 localhost kernel: Call Trace:
May 24 15:12:07 localhost kernel: [<c01321a4>] worker_thread+0x1eb/0x2f0
May 24 15:12:07 localhost kernel: [<c014c4e2>] cache_reap+0x0/0x273
May 24 15:12:07 localhost kernel: [<c011b9f2>] default_wake_function+0x0/0xc
May 24 15:12:07 localhost kernel: [<c03015c9>] schedule+0x431/0x544
May 24 15:12:07 localhost kernel: [<c011b9f2>] default_wake_function+0x0/0xc
May 24 15:12:07 localhost kernel: [<c0131fb9>] worker_thread+0x0/0x2f0
May 24 15:12:07 localhost kernel: [<c0136f81>] kthread+0x69/0x91
May 24 15:12:07 localhost kernel: [<c0136f18>] kthread+0x0/0x91
May 24 15:12:07 localhost kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb
May 24 15:12:07 localhost kernel: Code: e9 05 01 00 00 6b 4b 3c 05 8b 53 40 01
ca 4a 89 d0 31 d2 f7 f1 89 c7 8b 4b 1c 8d 43 1c 39 c1 0f 84 e5 00 00 00 83 79
10 00 74 08 <0f> 0b e3 0a 15 43 31 c0 8b 01 8b 51 04 89 50 04 89 02 c7 41 04
2:26 p.m.
On Tuesday 24 May 2005 14:19, Steve Grubb wrote:
On Tuesday 24 May 2005 14:06, Timothy R. Chavez wrote:
> Can you also provide architecture, UP/SMP, etc
I just upgraded to the .48 kernel and did this:
-a entry,always -S mkdir
-a entry,always -S kill
-w /etc/passwd -k fk_passwd -p rwea
-w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
This kills the machine dead...well except for the blinking numlock & caps lock
lights.
So this message you're getting is indicative of a leaked reference. I'm curious
to know if you get the error when you just insert those watches... do you know?
-tim
2:27 p.m.
On Tuesday 24 May 2005 15:26, Timothy R. Chavez wrote:
I'm curious to know if you get the error when you just insert
those
watches... do you know?
That's all I did was insert them. I had them in a file and used auditctl -R to
load them and the machine froze...well except for the blinking lights.
-Steve
2:43 p.m.
On Tuesday 24 May 2005 14:27, Steve Grubb wrote:
On Tuesday 24 May 2005 15:26, Timothy R. Chavez wrote:
> I'm curious to know if you get the error when you just insert those
> watches... do you know?
That's all I did was insert them. I had them in a file and used auditctl -R to
load them and the machine froze...well except for the blinking lights.
-Steve
Well I saw that you inserted rules _and_ watches. I'm curious to know if the
behavior appears if you _just_ insert watches.
--
-tim
2:56 p.m.
On Tue, 2005-05-24 at 15:19 -0400, Steve Grubb wrote:
On Tuesday 24 May 2005 14:06, Timothy R. Chavez wrote:
> Can you also provide architecture, UP/SMP, etc
I just upgraded to the .48 kernel and did this:
-a entry,always -S mkdir
-a entry,always -S kill
-w /etc/passwd -k fk_passwd -p rwea
-w /var/run/dbus/system_bus_socket -k dbus-test -p rwea
This kills the machine dead...well except for the blinking numlock & caps lock
lights.
so far, i am unable to reproduce on audit.48 up or smp.
[root@localhost ~]# auditctl -l
AUDIT_LIST: entry always syscall=mkdir
AUDIT_LIST: entry always syscall=kill
AUDIT_WATCH_LIST: dev=8:2, path=/etc/passwd, filterkey=fk_passwd,
perms=15, valid=0
AUDIT_WATCH_LIST: dev=8:2, path=/var/run/dbus/system_bus_socket,
filterkey=, perms=15, valid=0
u[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.9-5.0.3.EL.audit.48smp #1 SMP Mon May 23
16:33:18 EDT 2005 i686 i686 i386 GNU/Linux
[root@localhost ~]# auditctl -l
AUDIT_LIST: entry always syscall=mkdir
AUDIT_LIST: entry always syscall=kill
AUDIT_WATCH_LIST: dev=8:2, path=/etc/passwd, filterkey=, perms=15,
valid=0
AUDIT_WATCH_LIST: dev=8:2, path=/var/run/dbus/system_bus_socket,
filterkey=dbus-test, perms=15, valid=0
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.9-5.0.3.EL.audit.48 #1 Mon May 23
16:24:01 EDT 2005 i686 i686 i386 GNU/Linux
steve, can you reproduce it reliably?
rob.
3:09 p.m.
On Tuesday 24 May 2005 15:56, Rob Myers wrote:
steve, can you reproduce it reliably?
Just like clockwork.
Here's another one just doing the watches - no rules this time. It looks a
little different:
May 24 15:57:22 localhost kernel: Unable to handle kernel paging request at
virtual address f97cff90
May 24 15:57:22 localhost kernel: printing eip:
May 24 15:57:22 localhost kernel: c014170c
May 24 15:57:22 localhost kernel: *pde = 00000000
May 24 15:57:22 localhost kernel: Oops: 0000 [#1]
May 24 15:57:22 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 24 15:57:22 localhost kernel: CPU: 0
May 24 15:57:22 localhost kernel: EIP: 0060:[<c014170c>] Not tainted VLI
May 24 15:57:22 localhost kernel: EFLAGS: 00010282 (2.6.9-5.0.3.EL.audit.48)
May 24 15:57:22 localhost kernel: EIP is at audit_syscall_exit+0x340/0x3be
May 24 15:57:22 localhost kernel: eax: effef060 ebx: f97cff8c ecx:
00000006 edx: 0000004c
May 24 15:57:22 localhost kernel: esi: e832e780 edi: 00000000 ebp:
e82f4800 esp: e7b9ef94
May 24 15:57:22 localhost kernel: ds: 007b es: 007b ss: 0068
May 24 15:57:22 localhost kernel: Process socket (pid: 1831,
threadinfo=e7b9e000 task=e832e780)
May 24 15:57:22 localhost kernel: Stack: bff1cea0 00000010 00000000 e832e780
e7b9efc4 00000001 e7b9e000 c010b49b
May 24 15:57:22 localhost kernel: 00000003 00000004 00000005 c0303742
00000003 bff1ad30 ffffffff 00000004
May 24 15:57:22 localhost kernel: 00000005 bff1d8c8 ffffff92 0000007b
0000007b 00000066 00a947a2 00000073
May 24 15:57:22 localhost kernel: Call Trace:
May 24 15:57:22 localhost kernel: [<c010b49b>] do_syscall_trace+0x2f/0xc8
May 24 15:57:22 localhost kernel: [<c0303742>] syscall_exit_work+0x12/0x18
May 24 15:57:22 localhost kernel: Code: 3c 8b 13 85 d2 74 0a a1 14 6f 40 c0 e8
93 a9 00 00 47 83 c3 1c 3b 7d 38 7c e7 c7 45 38 00 00 00 00 8b 9d 70 02 00 00
85 db 74 41 <81> 7b 04 7a 05 00 00 75 27 8b 43 08 e8 73 b0 03 00 8b 53 0c 85
3:17 p.m.
On Tue, 2005-05-24 at 16:09 -0400, Steve Grubb wrote:
May 24 15:57:22 localhost kernel: EIP: 0060:[<c014170c>]
Not tainted VLI
May 24 15:57:22 localhost kernel: EFLAGS: 00010282 (2.6.9-5.0.3.EL.audit.48)
May 24 15:57:22 localhost kernel: EIP is at audit_syscall_exit+0x340/0x3be
list *0xc014170c
--
dwmw2
3:38 p.m.
On Tuesday 24 May 2005 15:09, Steve Grubb wrote:
On Tuesday 24 May 2005 15:56, Rob Myers wrote:
> steve, can you reproduce it reliably?
Just like clockwork.
I noticed that I wasn't putting my reference back to my wentry in the
audit_free_aux() function, only in audit_log_exit() *cough*
Though, on a separate but some-what related tangent, why have this in
audit_log_exit():
case AUDIT_AVC_PATH: {
struct audit_aux_data_path *axi = (void *)aux;
audit_log_d_path(ab, "path=", axi->dentry,
axi->mnt);
-> dput(axi->dentry);
-> mntput(axi->mnt);
break; }
In theory, you're going to have to call audit_free_aux() and it will be
dealt with there, right?
-tim
Here's another one just doing the watches - no rules this time.
It looks a
little different:
May 24 15:57:22 localhost kernel: Unable to handle kernel paging request at
virtual address f97cff90
May 24 15:57:22 localhost kernel: printing eip:
May 24 15:57:22 localhost kernel: c014170c
May 24 15:57:22 localhost kernel: *pde = 00000000
May 24 15:57:22 localhost kernel: Oops: 0000 [#1]
May 24 15:57:22 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 24 15:57:22 localhost kernel: CPU: 0
May 24 15:57:22 localhost kernel: EIP: 0060:[<c014170c>] Not tainted
VLI
May 24 15:57:22 localhost kernel: EFLAGS: 00010282
(2.6.9-5.0.3.EL.audit.48)
May 24 15:57:22 localhost kernel: EIP is at
audit_syscall_exit+0x340/0x3be
May 24 15:57:22 localhost kernel: eax: effef060 ebx: f97cff8c ecx:
00000006 edx: 0000004c
May 24 15:57:22 localhost kernel: esi: e832e780 edi: 00000000 ebp:
e82f4800 esp: e7b9ef94
May 24 15:57:22 localhost kernel: ds: 007b es: 007b ss: 0068
May 24 15:57:22 localhost kernel: Process socket (pid: 1831,
threadinfo=e7b9e000 task=e832e780)
May 24 15:57:22 localhost kernel: Stack: bff1cea0 00000010 00000000 e832e780
e7b9efc4 00000001 e7b9e000 c010b49b
May 24 15:57:22 localhost kernel: 00000003 00000004 00000005 c0303742
00000003 bff1ad30 ffffffff 00000004
May 24 15:57:22 localhost kernel: 00000005 bff1d8c8 ffffff92 0000007b
0000007b 00000066 00a947a2 00000073
May 24 15:57:22 localhost kernel: Call Trace:
May 24 15:57:22 localhost kernel: [<c010b49b>] do_syscall_trace+0x2f/0xc8
May 24 15:57:22 localhost kernel: [<c0303742>] syscall_exit_work+0x12/0x18
May 24 15:57:22 localhost kernel: Code: 3c 8b 13 85 d2 74 0a a1 14 6f 40 c0
e8
93 a9 00 00 47 83 c3 1c 3b 7d 38 7c e7 c7 45 38 00 00 00 00 8b 9d 70
02 00
00
85 db 74 41 <81> 7b 04 7a 05 00 00 75 27 8b 43 08 e8 73 b0 03
00 8b 53 0c 85
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
-tim
11:23 a.m.
On Tue, 2005-05-24 at 15:38 -0500, Timothy R. Chavez wrote:
I noticed that I wasn't putting my reference back to my wentry in
the
audit_free_aux() function, only in audit_log_exit() *cough*
Though, on a separate but some-what related tangent, why have this in
audit_log_exit():
case AUDIT_AVC_PATH: {
struct audit_aux_data_path *axi = (void *)aux;
audit_log_d_path(ab, "path=", axi->dentry,
axi->mnt);
-> dput(axi->dentry);
-> mntput(axi->mnt);
break; }
In theory, you're going to have to call audit_free_aux() and it will be
dealt with there, right?
That was my initial take as well when I first posted the patch, but Dave
pointed out that I needed to handle the dput/mntput here as well because
the existing code is removing each aux entry and freeing it at the tail
of the loop, so context->aux ends up being NULL upon leaving the loop.
Thus, the subsequent audit_free_aux() does nothing (except in the case
where audit_log_start failed in the loop, causing it to retry the same
aux entry endlessly?). Not clear why this approach is taken.
--
Stephen Smalley
National Security Agency
1:08 p.m.
On Wednesday 25 May 2005 11:23, Stephen Smalley wrote:
On Tue, 2005-05-24 at 15:38 -0500, Timothy R. Chavez wrote:
> I noticed that I wasn't putting my reference back to my wentry in the
> audit_free_aux() function, only in audit_log_exit() *cough*
>
> Though, on a separate but some-what related tangent, why have this in
> audit_log_exit():
>
> case AUDIT_AVC_PATH: {
> struct audit_aux_data_path *axi = (void *)aux;
> audit_log_d_path(ab, "path=", axi->dentry,
axi->mnt);
> -> dput(axi->dentry);
> -> mntput(axi->mnt);
> break; }
>
> In theory, you're going to have to call audit_free_aux() and it will be
> dealt with there, right?
That was my initial take as well when I first posted the patch, but Dave
pointed out that I needed to handle the dput/mntput here as well because
the existing code is removing each aux entry and freeing it at the tail
of the loop, so context->aux ends up being NULL upon leaving the loop.
Thus, the subsequent audit_free_aux() does nothing (except in the case
where audit_log_start failed in the loop, causing it to retry the same
aux entry endlessly?). Not clear why this approach is taken.
I think we should just rely on on audit_free_aux() to take care of this for us
because it's not obvious otherwise. The trade-off is that we have to iterate
through the list one more time, but I think it's a good trade-off personally.
-tim
3:38 p.m.
On Wed, 2005-05-25 at 13:08 -0500, Timothy R. Chavez wrote:
--
dwmw2
I think we should just rely on on audit_free_aux() to take care of
this for us
because it's not obvious otherwise. The trade-off is that we have to iterate
through the list one more time, but I think it's a good trade-off personally.
Yeah, I agree. When I first implemented the aux list it was all stuff
that could just be freed in the loop after it was printed. Now it's more
complex, it makes sense to free it only in audit_free_aux() as you
suggest. I'll do that.
7150
days inactive
7151
days old
linux-audit@lists.linux-audit.osci.io
14 comments
5 participants
participants (5)
-
David Woodhouse -
Rob Myers -
Stephen Smalley -
Steve Grubb -
Timothy R. Chavez