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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> > 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.

You are changing standards defined behaviour - so apps that rely on
correct behaviour maybe misbehave or become vulnerable in ways not
anticipated

A classic example here is SIGPIPE. What you are doing by dropping to
default signal behaviour is breaking various inetd style setups that know
the child will inherit SIGPIPE as SIG_IGN and therefore will cleanly
process network connection loss.

Instead the child will now suffer immediate termination and not
have a chance to clean up. 

So mucking with signal masks is actually not improving security - it's
randomly changing things - and randomly changing things to disagree with
the spec is a very very bad idea IMHO as you will harm correctly written
code.

> 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

No.

A signal handler function is cleared across a setuid exec so you can't
set an address and jump to it in the new binary. K&R thought of that
one ;)

A signal mask is inherited and this is *required to be so*. Changing it
breaks stuff and may itself introduce security problems.

Any setuid app has to be reasonably robust because it may get very
strange file handles, very strange signal masks, quotas, resource limits
and other stuff. Signals are just one trivial detail.

Clearing a lot of these is hard as you don't know what the resource
limits etc for the setuid target are and you don't want a pair of setuid
user A and user B apps co-operating to evade things.

The correct way to do most of this is not to use setuid apps run by the
user but to pass authority information to service daemons that run
services within a known non-user influencable environment in the first
place... the very daemons that randomly clearing the SIG_IGN on SIGPIPE
will break !

Alan