public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Alexander Viro <aviro@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: OBJ_PID records
Date: Mon, 01 Oct 2007 16:04:33 -0400	[thread overview]
Message-ID: <1191269073.3146.5.camel@localhost.localdomain> (raw)
In-Reply-To: <20071001185225.GM21685@devserv.devel.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 <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

  reply	other threads:[~2007-10-01 20:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2007-10-02 20:20             ` Steve Grubb
2007-09-28  3:25   ` Alexander Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1191269073.3146.5.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=aviro@redhat.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox