Re: Q: selinux_bprm_committed_creds() && signals/do_wait

On Wed, 2009-04-29 at 15:42 +0200, Oleg Nesterov wrote:
On 04/29, Stephen Smalley wrote:

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?

The callee can never setup the signal handler. Note that flush_old_exec()
does flush_signal_handlers() too. But it uses force_default == F.

Right, but it can set it to SIG_IGN, which was the problem in the
situation above.

OK, please forget this. I trust you even if can't understand ;)

My real concerns were SIGKILL and do_wait(), they were addressed.

Thanks!

Oleg.
--
Stephen Smalley
National Security Agency

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

Relevant Pages