From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: OBJ_PID records Date: Mon, 01 Oct 2007 16:04:33 -0400 Message-ID: <1191269073.3146.5.camel@localhost.localdomain> References: <200709211506.56322.sgrubb@redhat.com> <20070928032157.GI21685@devserv.devel.redhat.com> <200709280931.10126.sgrubb@redhat.com> <200709280939.57623.sgrubb@redhat.com> <20071001185225.GM21685@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071001185225.GM21685@devserv.devel.redhat.com> 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 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 > 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