2:06 p.m.
Hi,
I was noticing that I'm seeing OBJ_PID records sometimes when there is
MAC_POLICY_LOAD event. I didn't think these two would go together. I'm seeing
this:
type=OBJ_PID msg=audit(09/18/2007 06:26:21.236:216) : opid=3211
obj=user_u:system_r:unconfined_t:s0
type=SYSCALL msg=audit(09/18/2007 06:26:21.236:216) : arch=x86_64
syscall=write success=yes exit=1592854 a0=4 a1=2aaaaaae2000 a2=184e16 a3=0
items=0 ppid=3333 pid=3334 auid=sgrubb uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=load_policy
exe=/usr/sbin/load_policy subj=user_u:system_r:load_policy_t:s0 key=(null)
type=MAC_POLICY_LOAD msg=audit(09/18/2007 06:26:21.236:216) : policy loaded
auid=sgrubb
Shouldn't these only come out when kill (or its friends) is in effect? The
above syscall was a write. I don't think the current syscall is being taken
into account in audit_match_signal.
-Steve
2:21 p.m.
What are you running? I don't see the OBJ_PID record on a recent
RHEL5 U1 snapshot on ia64, but I only tried it once.
-- ljk
Steve Grubb wrote:
Hi,
I was noticing that I'm seeing OBJ_PID records sometimes when there is
MAC_POLICY_LOAD event. I didn't think these two would go together. I'm seeing
this:
type=OBJ_PID msg=audit(09/18/2007 06:26:21.236:216) : opid=3211
obj=user_u:system_r:unconfined_t:s0
type=SYSCALL msg=audit(09/18/2007 06:26:21.236:216) : arch=x86_64
syscall=write success=yes exit=1592854 a0=4 a1=2aaaaaae2000 a2=184e16 a3=0
items=0 ppid=3333 pid=3334 auid=sgrubb uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=load_policy
exe=/usr/sbin/load_policy subj=user_u:system_r:load_policy_t:s0 key=(null)
type=MAC_POLICY_LOAD msg=audit(09/18/2007 06:26:21.236:216) : policy loaded
auid=sgrubb
Shouldn't these only come out when kill (or its friends) is in effect? The
above syscall was a write. I don't think the current syscall is being taken
into account in audit_match_signal.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
1:40 p.m.
Started playing with this today, with no audit rules i was unable to
trigger the OBJ_PID issue. With a single syscall audit rule
-a entry,always -S adjtimex -S settimeofday -k time-change
i was unable to trigger the problem (might have just not left it long
enough, going back and trying again). With a single file watch I was
able to trigger the problem.
[root@dhcp59-192 audit]# auditctl -l
LIST_RULES: exit,always watch=/etc/localtime perm=wa key=time-change
[root@dhcp59-192 audit]# for i in `seq 1 500`; do load_policy; done &
[1] 17639
[root@dhcp59-192 audit]# for i in `seq 1 50`; do sleep 5; ausearch -m OBJ_PID; done &
[2] 17644
[root@dhcp59-192 audit]# <no matches>
<no matches>
<no matches>
<no matches>
<no matches>
<no matches>
<no matches>
<no matches>
----
time->Fri Sep 28 06:02:50 2007
type=OBJ_PID msg=audit(1190973770.581:4409): opid=1956
obj=system_u:system_r:syslogd_t:s0
type=SYSCALL msg=audit(1190973770.581:4409): arch=c000003e syscall=1 success=yes
exit=3893128 a0=4 a1=2ae984eee000 a2=3b6788 a3=0 items=0 ppid=17639 pid=17686
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
comm="load_policy" exe="/usr/sbin/load_policy"
subj=root:system_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=MAC_POLICY_LOAD msg=audit(1190973770.581:4409): policy loaded auid=4294967295
Interestingly on this machine the opid has ALWAYS been 1956 with
obj=syslogd_t. I don't however think there is anything special about
syslog though as that wasn't the obj in the messages sgrubb was getting,
although i do wonder if it was the same opid every time.....
-Eric
On Fri, 2007-09-21 at 15:06 -0400, Steve Grubb wrote:
Hi,
I was noticing that I'm seeing OBJ_PID records sometimes when there is
MAC_POLICY_LOAD event. I didn't think these two would go together. I'm seeing
this:
type=OBJ_PID msg=audit(09/18/2007 06:26:21.236:216) : opid=3211
obj=user_u:system_r:unconfined_t:s0
type=SYSCALL msg=audit(09/18/2007 06:26:21.236:216) : arch=x86_64
syscall=write success=yes exit=1592854 a0=4 a1=2aaaaaae2000 a2=184e16 a3=0
items=0 ppid=3333 pid=3334 auid=sgrubb uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=load_policy
exe=/usr/sbin/load_policy subj=user_u:system_r:load_policy_t:s0 key=(null)
type=MAC_POLICY_LOAD msg=audit(09/18/2007 06:26:21.236:216) : policy loaded
auid=sgrubb
Shouldn't these only come out when kill (or its friends) is in effect? The
above syscall was a write. I don't think the current syscall is being taken
into account in audit_match_signal.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
1:49 p.m.
On Thursday 27 September 2007 14:40:45 Eric Paris wrote:
Interestingly on this machine the opid has ALWAYS been 1956 with
obj=syslogd_t. I don't however think there is anything special about
syslog though as that wasn't the obj in the messages sgrubb was getting,
although i do wonder if it was the same opid every time.....
Seems like it. I have one example where I have 86 records in a row with the
same opid.
-Steve
----
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
type=SYSCALL msg=audit(09/20/2007 15:29:16.355:12775) : arch=x86_64
syscall=write success=yes exit=3786608 a0=5 a1=2aaaab878000 a2=39c770 a3=0
items=0 ppid=8343 pid=8345 auid=sgrubb uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=load_policy
exe=/usr/sbin/load_policy subj=system_u:system_r:load_policy_t:s0 key=(null)
type=MAC_POLICY_LOAD msg=audit(09/20/2007 15:29:16.355:12775) : policy loaded
auid=sgrubb
10:21 p.m.
On Thu, Sep 27, 2007 at 02:49:09PM -0400, Steve Grubb wrote:
On Thursday 27 September 2007 14:40:45 Eric Paris wrote:
> Interestingly on this machine the opid has ALWAYS been 1956 with
> obj=syslogd_t. ??I don't however think there is anything special about
> syslog though as that wasn't the obj in the messages sgrubb was getting,
> although i do wonder if it was the same opid every time.....
Seems like it. I have one example where I have 86 records in a row with the
same opid.
-Steve
----
type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287
obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
Er... And what has pid 2287 on that box?
8:31 a.m.
On Thursday 27 September 2007 23:21:57 Alexander Viro wrote:
> type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) :
opid=2287
> obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
Er... And what has pid 2287 on that box?
I am reasonably certain that its gdm given the selinux label.
-Steve
8:39 a.m.
On Friday 28 September 2007 09:31:09 Steve Grubb wrote:
> > type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) :
opid=2287
> > obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
>
> Er... And what has pid 2287 on that box?
I am reasonably certain that its gdm given the selinux label.
Scratch that, I forgot to include "server" in my grep. That looks like
Xorg's
process label. So, its the X server.
-Steve
1:52 p.m.
On Fri, Sep 28, 2007 at 09:39:57AM -0400, Steve Grubb wrote:
On Friday 28 September 2007 09:31:09 Steve Grubb wrote:
> > > type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287 ?
> > > obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
> >
> > Er... And what has pid 2287 on that box?
>
> I am reasonably certain that its gdm given the selinux label.
Scratch that, I forgot to include "server" in my grep. That looks like
Xorg's
process label. So, its the X server.
OK, I think I see what's going on:
a) we are too cautious about audit_signals; need to exclude rules
that have AUDIT_DEV{MAJOR,MINOR}, AUDIT_INODE, AUDIT_WATCH, AUDIT_PERM.
None of those will trigger on signal-sending syscall
b) more important, we should not touch async signals - basically,
when kernel decides to send SIGIO/SIGURG we obviously should not screw with
current->audit_context. Note that we already have that check, right in the
caller of audit_signal_info() (that is, when we decide if current-based
permissions checks apply). So we simply need to move audit_signal_info()
a bit down - after we'd decided that it's not an async signal and before
the permission checks. Patch below does just that.
diff -urN linux-2.6.22.x86_64/kernel/signal.c foo/kernel/signal.c
--- linux-2.6.22.x86_64/kernel/signal.c 2007-10-01 13:18:10.000000000 -0400
+++ foo/kernel/signal.c 2007-10-01 14:45:35.000000000 -0400
@@ -532,18 +532,18 @@
if (!valid_signal(sig))
return error;
- error = audit_signal_info(sig, t); /* Let audit system see the signal */
- if (error)
- return error;
-
- error = -EPERM;
- if ((info == SEND_SIG_NOINFO || (!is_si_special(info) && SI_FROMUSER(info)))
- && ((sig != SIGCONT) ||
- (process_session(current) != process_session(t)))
- && (current->euid ^ t->suid) && (current->euid ^
t->uid)
- && (current->uid ^ t->suid) && (current->uid ^ t->uid)
- && !capable(CAP_KILL))
+ if (info == SEND_SIG_NOINFO || (!is_si_special(info) && SI_FROMUSER(info))) {
+ error = audit_signal_info(sig, t); /* Let audit system see the signal */
+ if (error)
+ return error;
+ error = -EPERM;
+ if (((sig != SIGCONT) ||
+ (process_session(current) != process_session(t)))
+ && (current->euid ^ t->suid) && (current->euid ^
t->uid)
+ && (current->uid ^ t->suid) && (current->uid ^ t->uid)
+ && !capable(CAP_KILL))
return error;
+ }
return security_task_kill(t, info, sig, 0);
}
3:04 p.m.
On Mon, 2007-10-01 at 14:52 -0400, Alexander Viro wrote:
On Fri, Sep 28, 2007 at 09:39:57AM -0400, Steve Grubb wrote:
> On Friday 28 September 2007 09:31:09 Steve Grubb wrote:
> > > > type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287 ?
> > > > obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
> > >
> > > Er... And what has pid 2287 on that box?
> >
> > I am reasonably certain that its gdm given the selinux label.
>
> Scratch that, I forgot to include "server" in my grep. That looks like
Xorg's
> process label. So, its the X server.
OK, I think I see what's going on:
a) we are too cautious about audit_signals; need to exclude rules
that have AUDIT_DEV{MAJOR,MINOR}, AUDIT_INODE, AUDIT_WATCH, AUDIT_PERM.
None of those will trigger on signal-sending syscall
right. even if we do fix this, one just needs to add an audit rule for
signals (any rule at all) and still get the async bogus crap. Fixing
this means we will have audit_signals == 0 more of the time and save us
a little performance, but as you agree it isn't critical.
b) more important, we should not touch async signals - basically,
when kernel decides to send SIGIO/SIGURG we obviously should not screw with
current->audit_context. Note that we already have that check, right in the
caller of audit_signal_info() (that is, when we decide if current-based
permissions checks apply). So we simply need to move audit_signal_info()
a bit down - after we'd decided that it's not an async signal and before
the permission checks. Patch below does just that.
I assume testing resulted in no audit signals when there shouldn't be?
If so the patch and logic look good to me.
Ack-by: Eric Paris <eparis(a)redhat.com>
diff -urN linux-2.6.22.x86_64/kernel/signal.c foo/kernel/signal.c
--- linux-2.6.22.x86_64/kernel/signal.c 2007-10-01 13:18:10.000000000 -0400
+++ foo/kernel/signal.c 2007-10-01 14:45:35.000000000 -0400
@@ -532,18 +532,18 @@
if (!valid_signal(sig))
return error;
- error = audit_signal_info(sig, t); /* Let audit system see the signal */
- if (error)
- return error;
-
- error = -EPERM;
- if ((info == SEND_SIG_NOINFO || (!is_si_special(info) && SI_FROMUSER(info)))
- && ((sig != SIGCONT) ||
- (process_session(current) != process_session(t)))
- && (current->euid ^ t->suid) && (current->euid ^
t->uid)
- && (current->uid ^ t->suid) && (current->uid ^ t->uid)
- && !capable(CAP_KILL))
+ if (info == SEND_SIG_NOINFO || (!is_si_special(info) && SI_FROMUSER(info))) {
+ error = audit_signal_info(sig, t); /* Let audit system see the signal */
+ if (error)
+ return error;
+ error = -EPERM;
+ if (((sig != SIGCONT) ||
+ (process_session(current) != process_session(t)))
+ && (current->euid ^ t->suid) && (current->euid ^
t->uid)
+ && (current->uid ^ t->suid) && (current->uid ^
t->uid)
+ && !capable(CAP_KILL))
return error;
+ }
return security_task_kill(t, info, sig, 0);
}
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3:20 p.m.
On Monday 01 October 2007 14:52:25 Alexander Viro wrote:
On Fri, Sep 28, 2007 at 09:39:57AM -0400, Steve Grubb wrote:
> On Friday 28 September 2007 09:31:09 Steve Grubb wrote:
> > > > type=OBJ_PID msg=audit(09/20/2007 15:29:16.355:12775) : opid=2287 ?
> > > > obj=system_u:system_r:xdm_xserver_t:s0-s0:c0.c1023
> > >
> > > Er... And what has pid 2287 on that box?
> >
> > I am reasonably certain that its gdm given the selinux label.
>
> Scratch that, I forgot to include "server" in my grep. That looks like
> Xorg's process label. So, its the X server.
OK, I think I see what's going on:
a) we are too cautious about audit_signals; need to exclude rules
that have AUDIT_DEV{MAJOR,MINOR}, AUDIT_INODE, AUDIT_WATCH, AUDIT_PERM.
None of those will trigger on signal-sending syscall
b) more important, we should not touch async signals - basically,
when kernel decides to send SIGIO/SIGURG we obviously should not screw with
current->audit_context. Note that we already have that check, right in the
caller of audit_signal_info() (that is, when we decide if current-based
permissions checks apply). So we simply need to move audit_signal_info()
a bit down - after we'd decided that it's not an async signal and before
the permission checks. Patch below does just that.
This seems to fix it on my machine. Reloaded policy many times and haven't
seen a recurrance.
Acked-by: Steve Grubb <sgrubb(a)redhat.com>
diff -urN linux-2.6.22.x86_64/kernel/signal.c foo/kernel/signal.c
--- linux-2.6.22.x86_64/kernel/signal.c 2007-10-01 13:18:10.000000000 -0400
+++ foo/kernel/signal.c 2007-10-01 14:45:35.000000000 -0400
@@ -532,18 +532,18 @@
if (!valid_signal(sig))
return error;
- error = audit_signal_info(sig, t); /* Let audit system see the signal */
- if (error)
- return error;
-
- error = -EPERM;
- if ((info == SEND_SIG_NOINFO || (!is_si_special(info) &&
SI_FROMUSER(info))) - && ((sig != SIGCONT) ||
- (process_session(current) != process_session(t)))
- && (current->euid ^ t->suid) && (current->euid ^
t->uid)
- && (current->uid ^ t->suid) && (current->uid ^ t->uid)
- && !capable(CAP_KILL))
+ if (info == SEND_SIG_NOINFO || (!is_si_special(info) &&
SI_FROMUSER(info))) { + error = audit_signal_info(sig, t); /* Let audit
system see the signal */ + if (error)
+ return error;
+ error = -EPERM;
+ if (((sig != SIGCONT) ||
+ (process_session(current) != process_session(t)))
+ && (current->euid ^ t->suid) && (current->euid ^
t->uid)
+ && (current->uid ^ t->suid) && (current->uid ^
t->uid)
+ && !capable(CAP_KILL))
return error;
+ }
return security_task_kill(t, info, sig, 0);
}
10:25 p.m.
On Thu, Sep 27, 2007 at 02:40:45PM -0400, Eric Paris wrote:
Interestingly on this machine the opid has ALWAYS been 1956 with
obj=syslogd_t. I don't however think there is anything special about
syslog though as that wasn't the obj in the messages sgrubb was getting,
although i do wonder if it was the same opid every time.....
Because the process in question is started from rc scripts and gets
the same PID on each boot on that box? PID 1956 sounds plausible in
that respect...
Same question: which process it actually is? I.e. what does
ps 1956
give on that box?
6290
days inactive
6301
days old
linux-audit@lists.linux-audit.osci.io
11 comments
4 participants
participants (4)
-
Alexander Viro -
Eric Paris -
Linda Knippers -
Steve Grubb