From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: OBJ_PID records Date: Tue, 2 Oct 2007 16:20:11 -0400 Message-ID: <200710021620.11947.sgrubb@redhat.com> References: <200709211506.56322.sgrubb@redhat.com> <200709280939.57623.sgrubb@redhat.com> <20071001185225.GM21685@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071001185225.GM21685@devserv.devel.redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Alexander Viro Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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 > 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); > }