* OBJ_PID records @ 2007-09-21 19:06 Steve Grubb 2007-09-21 19:21 ` Linda Knippers 2007-09-27 18:40 ` Eric Paris 0 siblings, 2 replies; 12+ messages in thread From: Steve Grubb @ 2007-09-21 19:06 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-21 19:06 OBJ_PID records Steve Grubb @ 2007-09-21 19:21 ` Linda Knippers 2007-09-21 19:29 ` Steve Grubb 2007-09-27 18:40 ` Eric Paris 1 sibling, 1 reply; 12+ messages in thread From: Linda Knippers @ 2007-09-21 19:21 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit 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@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-21 19:21 ` Linda Knippers @ 2007-09-21 19:29 ` Steve Grubb 0 siblings, 0 replies; 12+ messages in thread From: Steve Grubb @ 2007-09-21 19:29 UTC (permalink / raw) To: Linda Knippers; +Cc: linux-audit On Friday 21 September 2007 15:21:39 Linda Knippers wrote: > 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. This is rawhide, 2.6.23rc6git8 or something close. -Steve ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-21 19:06 OBJ_PID records Steve Grubb 2007-09-21 19:21 ` Linda Knippers @ 2007-09-27 18:40 ` Eric Paris 2007-09-27 18:49 ` Steve Grubb 2007-09-28 3:25 ` Alexander Viro 1 sibling, 2 replies; 12+ messages in thread From: Eric Paris @ 2007-09-27 18:40 UTC (permalink / raw) To: aviro; +Cc: linux-audit 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@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-27 18:40 ` Eric Paris @ 2007-09-27 18:49 ` Steve Grubb 2007-09-28 3:21 ` Alexander Viro 2007-09-28 3:25 ` Alexander Viro 1 sibling, 1 reply; 12+ messages in thread From: Steve Grubb @ 2007-09-27 18:49 UTC (permalink / raw) To: Eric Paris; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-27 18:49 ` Steve Grubb @ 2007-09-28 3:21 ` Alexander Viro 2007-09-28 13:31 ` Steve Grubb 0 siblings, 1 reply; 12+ messages in thread From: Alexander Viro @ 2007-09-28 3:21 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-28 3:21 ` Alexander Viro @ 2007-09-28 13:31 ` Steve Grubb 2007-09-28 13:39 ` Steve Grubb 0 siblings, 1 reply; 12+ messages in thread From: Steve Grubb @ 2007-09-28 13:31 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-28 13:31 ` Steve Grubb @ 2007-09-28 13:39 ` Steve Grubb 2007-10-01 18:52 ` Alexander Viro 0 siblings, 1 reply; 12+ messages in thread From: Steve Grubb @ 2007-09-28 13:39 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-28 13:39 ` Steve Grubb @ 2007-10-01 18:52 ` Alexander Viro 2007-10-01 20:04 ` Eric Paris 2007-10-02 20:20 ` Steve Grubb 0 siblings, 2 replies; 12+ messages in thread From: Alexander Viro @ 2007-10-01 18:52 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit 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); } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-10-01 18:52 ` Alexander Viro @ 2007-10-01 20:04 ` Eric Paris 2007-10-02 20:20 ` Steve Grubb 1 sibling, 0 replies; 12+ messages in thread From: Eric Paris @ 2007-10-01 20:04 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-audit 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@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@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-10-01 18:52 ` Alexander Viro 2007-10-01 20:04 ` Eric Paris @ 2007-10-02 20:20 ` Steve Grubb 1 sibling, 0 replies; 12+ messages in thread From: Steve Grubb @ 2007-10-02 20:20 UTC (permalink / raw) To: Alexander Viro; +Cc: linux-audit 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@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); > } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OBJ_PID records 2007-09-27 18:40 ` Eric Paris 2007-09-27 18:49 ` Steve Grubb @ 2007-09-28 3:25 ` Alexander Viro 1 sibling, 0 replies; 12+ messages in thread From: Alexander Viro @ 2007-09-28 3:25 UTC (permalink / raw) To: Eric Paris; +Cc: linux-audit 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-10-02 20:20 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-09-21 19:06 OBJ_PID records Steve Grubb 2007-09-21 19:21 ` Linda Knippers 2007-09-21 19:29 ` Steve Grubb 2007-09-27 18:40 ` Eric Paris 2007-09-27 18:49 ` Steve Grubb 2007-09-28 3:21 ` Alexander Viro 2007-09-28 13:31 ` Steve Grubb 2007-09-28 13:39 ` Steve Grubb 2007-10-01 18:52 ` Alexander Viro 2007-10-01 20:04 ` Eric Paris 2007-10-02 20:20 ` Steve Grubb 2007-09-28 3:25 ` Alexander Viro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox