public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Oleg Nesterov <oleg@redhat.com>
Cc: James Morris <jmorris@namei.org>,
	David Howells <dhowells@redhat.com>,
	Eric Paris <eparis@parisplace.org>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Q: selinux_bprm_committed_creds() && signals/do_wait
Date: Wed, 29 Apr 2009 09:16:54 -0400	[thread overview]
Message-ID: <1241011014.18249.192.camel@localhost.localdomain> (raw)
In-Reply-To: <20090429125606.GA27901@redhat.com>

On Wed, 2009-04-29 at 14:56 +0200, Oleg Nesterov wrote:
> On 04/29, Stephen Smalley wrote:
> >
> > On Wed, 2009-04-29 at 08:58 +0200, Oleg Nesterov wrote:
> > >
> > > Why do we need to s/IGN/DFL/ and why do we clear ->blocked ? How this can
> > > help from the security pov?
> >
> > We don't want the caller to be able to arrange conditions that prevent
> > correct handling of signals (e.g. SIGHUP) by the callee.  That was
> > motivated by a specific attack against newrole, but was a general issue
> > for any program that runs in a more trusted domain than its caller.
> 
> Still can't understand...
> 
> If the new image runs in a more trusted domain, then we should not change
> SIG_IGN to SIG_DFL ?
> 
> For example, a user does "nohup setuid_app". Now, why should we change
> SIG_IGN to SIG_DFL for SIGHUP? This makes setuid_app more "vulnerable"
> to SIGHUP, not more "protected". Confused.

Not if the app was depending on the default handler for SIGHUP to
correctly handle vhangup().  The point is that we don't necessarily
trust the caller to define the handling behavior for signals in the
callee.  If we trust the caller to do so, then we can grant the
corresponding permission.

newrole scenario was to run it nohup, logout, wait for other user to
login on same tty, trigger termination of newrole'd child shell, and
have newrole relabel other user's tty to attacker's sid.

> OK. Since I don't understand the security magic, you can just ignore me.
> But I will appreciate any explanation for dummies ;)
> 
> > As I recall, I based the logic in part on existing logic in
> > call_usermodehelper().
> 
> ____call_usermodehelper() does this because we should not exec a user-space
> application with SIGKILL/SIGSTOP ignored/blocked. We don't have this problem
> when user-space execs.

But we still have the problem of the caller setting up the signal
handlers or blocked signal mask prior to exec'ing the privileged
program, right?

-- 
Stephen Smalley
National Security Agency


  reply	other threads:[~2009-04-29 13:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 22:30 Q: selinux_bprm_committed_creds() && signals/do_wait Oleg Nesterov
2009-04-28 23:33 ` Oleg Nesterov
2009-04-29 16:01   ` [PATCH] do_wait: do take security_task_wait() into account Oleg Nesterov
2009-04-30 20:31     ` Roland McGrath
2009-04-30 22:51     ` James Morris
2009-05-06 11:46       ` Stephen Smalley
2009-04-29  0:29 ` Q: selinux_bprm_committed_creds() && signals/do_wait James Morris
2009-04-29  6:58   ` Oleg Nesterov
2009-04-29 10:02     ` David Howells
2009-04-29 10:25       ` Oleg Nesterov
2009-04-29 11:17         ` David Howells
2009-04-29 11:55           ` Oleg Nesterov
2009-04-29 12:42             ` David Howells
2009-04-29 12:45               ` David Howells
2009-04-29 13:28                 ` Oleg Nesterov
2009-04-30  0:37                   ` James Morris
2009-04-29 12:20     ` Stephen Smalley
2009-04-29 12:56       ` Oleg Nesterov
2009-04-29 13:16         ` Stephen Smalley [this message]
2009-04-29 13:42           ` Oleg Nesterov
2009-04-29 13:43             ` Stephen Smalley
2009-04-29 14:47           ` Alan Cox
2009-04-29 15:39             ` Stephen Smalley
2009-04-29 13:18 ` Stephen Smalley
2009-04-29 13:30   ` Oleg Nesterov
2009-04-29 14:02   ` ptrace: selinux_bprm_committed_creds: simplify __wake_up_parent() code and s/parent/real_parent/ Oleg Nesterov
2009-04-29 14:08     ` Oleg Nesterov
2009-04-30 22:44       ` Roland McGrath
2009-05-03 20:10         ` Oleg Nesterov
2009-05-04 17:38           ` Roland McGrath
2009-04-30  0:38     ` James Morris
2009-04-30 22:38     ` Roland McGrath
2009-04-29 14:48 ` Q: selinux_bprm_committed_creds() && signals/do_wait Alan Cox
2009-05-01  0:02 ` Roland McGrath
2009-05-01  0:44   ` David Howells
2009-05-01  0:50     ` Roland McGrath
2009-05-03 20:21   ` Oleg Nesterov
2009-05-04 17:34     ` Roland McGrath

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=1241011014.18249.192.camel@localhost.localdomain \
    --to=sds@tycho.nsa.gov \
    --cc=dhowells@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@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