Robert Milkowski a écrit :
Hello Darren,
Wednesday, April 1, 2009, 4:39:29 PM, you wrote:
.../...
Still I don't understand why process with ALL privileges running in a
global zone can't change another process L set via exposed API. There
isn't additional risk as such a process could do in in principle via
"/dev/kmem" anyway.
Perhaps because kernel zones definition structure embed there own privileges
set that are capping all processes which are attached to the zone.
Changing a non global process L privset would mean changing the zone L priv
set deducted from limitpriv. Also, some privileges are forbidden in a local
zone,
which are checked from the limitpriv of the zone at boot time (i.e.
dtrace_kernel).
It should be enforced that those forbidden privileges cannot be dynamically
setted.
Also, it is true that accessing kernel memory lets you change it's content, but
I am not sure changing one process credential sub structure content would be
enough,
as I suspect zone privilege capping to be made dynamically at run time.
That would mean you would have to hit and grant zone with the extra privilege
in it's limit
set as well. As a consequence, any process running with the "all" limit set in
that zone
would automatically have it in it's limit set as well. (i.e. any new root shell
run in the non global
zone).
Far being your target I guess, and also a security issue...
Any comments/corrections someone ?
My 2 cents,
Bruno.
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
