casper....@sun.com wrote:
The above code change would allow growing L set if new L' set is a subset
of the effective set of the calling process.
What would be the impact? Would it break anything?
The limit has been designed as a limit you cannot escape.
Changing that would break a promise the privilege system makes.
My question then is: who do you want to give privileges?
Specifically in the case of a zone, the limit set clearly defines with a
zone can do; allowing other processes to change it, even from the global
zone, would violate the assumption that a zone is limited to the limit set
in the zsched (init) process.
So one particular reason is this: making sure a number of privileged
application cannot conspire to start a process with even more privileges.
In Trusted Solaris, we had I, E and P. But I'm not a "Trusted" person,
but someone who wanted to make Solaris harder to break. That's why we
invented the "Limit set"; the set you cannot escape. It turned out to be
very useful when implementing zones and also allowing a "root user"
automatic privilege conversion.
In Trusted Solaris (all versions from 1.x up through 8) there were two
other sets A and F, but L didn't exist. Both A and F were persistent
filesystem sets. The A set was the maximum allowed for any binary and
was by default empty unless explicitly setup by the admin and on exec
acted similar to what happens with L. The F set was a set of forced
privs and a concept we so dearly need in OpenSolaris - it would allow us
to have programs like /usr/bin/ping that only need a single (or small
number) of privileges not be setuid root (and in the case of ping
privilege bracketed); it would also stop the hacks like what we have for
cdrecord.
In my perfect privilege system we would have all of P,I,E,L,F,A. Now
that OpenSolaris has moved to ZFS root and we have a more complete
system/xattr system we could reintroduced the A and F sets.
--
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
