Peter, I'm not clear on the scope of the proposal. Do you depend on enumerating all of the classes for which delegates would be needed? How would you interpose the delegate?
As an example, I think you propose that if code in a domain has a socket open on a port for which access is later revoked, the code should be denied further read/write access to the socket. -Should the socket be left open or closed? -Was a delegate introduced and where? -Can the code use reflection to bypass the delegate? -Is reflection denied generally? Thanks, Fred On Sat, Aug 7, 2010 at 2:10 AM, Peter Firmstone <[email protected]> wrote: > Please help identify any fallacies or oversights in the following arguments. > > A Permission may be revoked, at any point in time after a revocation, > untrusted code may hold a reference to a privileged object. > > Some Permission's protect methods, such as Thread.interrupt(), these are > effectively revoked with the existing Java security model, however other > objects are only protected in their constructor, the responsibility being on > the trusted code, not to let their references escape, such as > FileOutputStream. > > The moment code holding a reference becomes untrusted, the reference has > escaped. > > Instead of using a GuardedObject, or checking permission in constructors, to > deal with Permission's that can be revoked, we need to encapsulate the > object that needs protection with a SecurityDelegate. > > During a checkPermission call, the current Thread's AccessControlContext is > obtained, and (gross simplification) is asked to checkPermission. The > AccessControlContext contains all the ProtectionDomain's on the stack, all > ProtectionDomains on the stack must have the Permission for it to succeed. > The ProtectionDomain's contained by the AccessControlContext are related to > the class and object methods called and returned, the ProtectionDomain's are > dynamically added or removed. > > So the thinking behind the SecurityDelegate's private check method is that > an object must be protected in a dynamically changing environment: > > 1. Has the RevokeableDynamicPolicy advised that a check must be > performed? > 2. Is this the same thread that the last security check was made > against? If we haven't been advised that there is a reduction of > trust in our dynamic Security environment and the last > checkPermission call succeeded on this thread, then we can assume > that this Tread is still safe. > 3. If this thread is different or new, then we must checkPermission, > regardless of whether trust has changed recently or not. > > The costs: > > 1. Multi-threading is penalised (although a WeakMap could be > utilised, with threads as keys, and boolean check values, where > all are set true by the notify() call). > 2. The three "if" calls on every method invocation, check, null and > == Thread. > 3. Replicating the check method on all implementers (this will > require a helper class to implement the check). > 4. The RevokeableDynamicPolicy will need to notify all > SecurityDelegate's every time a reduction in trust occurs, it will > rely on GC to clean up and remove SecurityDelegates. > > The assumption is if the current Thread was trustworthy last call and the > environment hasn't experienced a reduction of trust, we can still trust this > thread. There is of course a risk that a Thread may have a new > ProtectionDomain on it's stack that isn't trusted, however this could still > happen in the case of the guarded object, where the environment doesn't > experience a reduction of trust and the trusted code must be trusted not to > let the reference escape it's own ProtectionDomain. Any code that > experiences a reduction of trust will receive an AccessControlException. > > Cheers, > > Peter.
