Messages in this thread | | | Subject | Re: Q: selinux_bprm_committed_creds() && signals/do_wait | From | Stephen Smalley <> | Date | Wed, 29 Apr 2009 09:43:03 -0400 |
| |
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
| |