James Carlson wrote: > 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.
Is it practical to design a generic "start this as that user, revoking *all* special privileges and all relationships with me" mechanism? It seems like failing to cover *some* case or other has been the root of more than one security hole. I'm not sure it's possible, since each individual case will probably have a few special things that it *doesn't* want severed, but it'd be nice if it was. This seems related to (but completely distinct from) the old problem of how to daemonize a process, how to completely divorce it from the terminal session that might have started it. That problem, happily, is completely solved by SMF. > 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. abort() seems simpler. All you have to do is trigger a core dump. Shell equivalents left as an exercise for the reader.
