David Powell writes:
> > Interesting. I wonder if that's really the right answer there.
> >
> > Wouldn't it be more correct to have sendmail create a new process
> > contract when it wants to run an executable $HOME/.forward or "|"
> > target in /etc/aliases?
>
> Yes. But I'll let you convince John to make the Solaris-specific
> changes to sendmail :)
An interesting subcase of this problem occurred to me when I was
talking to Mark Nelson about it, and I figured I'd share it because it
may have more serious implications.
Contracts are not (as far as I know) dissolved across a setuid/
seteuid and related credential change. The implication of this is
that your typical "do something for some user" service daemon -- one
designed for plain old UNIX and not Solaris contracts -- will do all
of the usual security checks on $HOME/blah before invoking it
carefully with the right credentials, but it will inevitably end up
handing over some dangerous keys to that subprocess, in the form of
that invisible contract.
In particular, if the user arranges to have his own invoked script
trigger a process outside of the contract to send him a fatal signal,
the original daemon will be taken out as a result. "pkill -QUIT blah"
ought to do the trick.
This is at least a theoretical DoS threat. It's also a privilege
escalation, in that a non-privileged user is able to perform an action
("svcadm restart") for which he has no privileges.
Avoiding that completely would require having contracts (like Least
Privilege behavior) become opt-in rather than opt-out. (Yes, I know
that's not a good answer.)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
