David Powell writes:
> James Carlson wrote:
> > 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.)
>
> No, it simply requires you to write your service description
> correctly.
As we've seen, that's far easier to say than to do. The contract
inheritance and its implications are not well-understood by the folks
maintaining all code that runs on Solaris.
For a random example, see the exec(2) man page. The only thing it
says about contracts is this:
All active contract templates are cleared (see contract(4)).
Ironically, the very next section of text starts with this header:
The new process also inherits the following attributes from
the calling process:
... but guess what it fails to mention. And the word "contract"
appears nowhere at all in the system(3C) man page.
I'm not trying to harp on the man pages (perhaps there are nits here),
but rather that I don't think the implications of this feature are
very well 'socialized' yet among Solaris developers.
As a counter-example, the "controlling terminal" concept is fairly
obscure for most junior (and even some not-so-junior) UNIX developers.
There are dozens of web sites with good FAQs explaining why a double
fork() is necessary to make a good daemon. Still, some do get it
wrong, and for that reason some OSes (most unfortunately not Solaris)
include a daemon() library call to do the "right things."
The contract concept is easily as obscure as a controlling terminal,
if not more so, and there's less support and common knowledge to draw
on.
--
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
