linux-kernel - Re: Q: selinux_bprm_committed_creds() && signals/do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1241011014.18249.192.camel@localhost.localdomain>
Date:	Wed, 29 Apr 2009 09:16:54 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	James Morris <jmorris@...ei.org>,
	David Howells <dhowells@...hat.com>,
	Eric Paris <eparis@...isplace.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Q: selinux_bprm_committed_creds() && signals/do_wait

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/