On Thu, 2005-04-14 at 09:11 -0400, Dan Sugalski wrote: > At 10:03 PM -0400 4/13/05, Michael Walter wrote:
> > > Each running thread has two sets of privileges -- the active > >> privileges and the enableable privileges. Active privs are what's > >> actually in force at the moment, and can be dropped at any time. The > >> enableable privs are ones that code can turn on. It's possible to > >> have an active priv that's not in the enableable set, in which case > >> the current running code is allowed to do something but as soon as > >> the privilege is dropped it can't be re-enabled. > > > >How can dropping a privilege for the duration of a (dynamic) scope be > >implemented? Does this need to be implemented via a parrot intrinsic, > >such as: > > > > without_privs(list_of_privs, code_to_be_run_without_these_privs); > > > >..or is it possible to do so with the primitives you sketched out above? > > When a priv is dropped it stays dropped until it's reinstated. If > code drops a priv that it can't re-enable then the priv is gone. > (There are going to be issues with privileges attached to > continuations, since this could potentially mean that dropped privs > get un-dropped when you invoke a return continuation, though dropping > a privilege could ripple up the return continuation chain) Reinstating privileges when you return is normal, since potentially malicious code and data has now been removed from the stack. If you do NOT do it this way, then every piece of code must know the privileges of every child piece of code it calls (bye-bye virtual base classes with user implementations). See http://research.microsoft.com/~adg/Publications/MSR-TR-2001-103.pdf The ability to explicitly reenable a privilege via an opcode, rather than via the removal of the malicious party from the computation (by return) is almost definitely a bad idea. If you protect this opcode using some security mechanism, you will rapidly find that security mechanism can supersede the functionality provided by the opcode. > > > Additionally, subroutines may be marked as having privileges, which > >> means that as long as control is inside the sub the priv in question > >> is enabled. This allows for code that has elevated privs, generally > >> system-level code. > > > >Does the code marking a subroutines must have any other privilege than > >the one it is marking the subroutine with? > > Dunno, that's something we'll need to work out. It's possible that > sub marking needs to be done externally -- that is, it's bytecode > metadata or something like that which requires system privileges of > some sort to set. (Though there are issues with that) Marking code as > privileged is really a system administration task, though we've not > really put much thought into administering a parrot system yet. Actually, what usually happens is that subroutines (etc) are associated with a responsible party (principal), and privileges are granted to the principal; thus finding out the privileges of an opcode requires an extra indirection. This is not a problem. > > > ... Non-continuation > >> invokables (subs and methods) maintain the current set of privs, plus > >> possibly adding the sub-specific privs. > >Same for closures? > > Yeah, I think so. No, as before. You cannot execute based only on static privileges - this is what Unix does, and the Unix model is broken. You need either a stack inspection or a data inspection model, or a combination of the two. Ask me if you want formal descriptions or implementation details of these models. S.
