Fred Oliver wrote:
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?
Revokeability is intended for downloaded code. I have some different
thoughts about possible implementations. The aim is to force re checking of
a Permission if a reduction of trust has occurred. To never allow references
to objects with privileged functionality to escape into unprivileged code.
The best place is to contain the privileged functionality within the
platform, the second best place, the client implementation or remotely in
the Server's service provider implementation.
Many Java classes are subject to Permission checks only in their
constructors, or obtained from checked methods or GuardedObjects, these
Permission's are not safe to grant if they are to be later revoked, object
references may still exist, enabling privileged functionality in untrusted
client code. What is needed are new Permission's that protect the methods
and creation of these classes by using a delegate to wrap the class,
depriving access via existing unchecked methods. I think a builder class
that returns OutputStreams (InputStreams, or any other etc), could build
many different types of OutputStreams but utilise the same delegate. This
could be provided as part of the Apache River platform.
What I want to do, is enable a client to provide Permission's temporarily
for a period of time to a ProtectionDomain, then revoke that Permission
later. I would want to do this if I utilise services from different servers
that utilise the same proxy code, so I can re-use the ClassLoader and
ProtectionDomain, to avoid having to use a new ClassLoader with re
verification of the same bytecode. This is based around provisioning of
proxy codebases, using Entry's to advertise the required codebase, version
and Permission's required.
I had thought about requiring all delegates register with the revokeable
policy, however now I'm having a change of heart, and think instead a class
or delegate could use a MethodAccessController, with two methods
checkPermission() and getPermission(). The RevokeableDynamicPolicy
implementer can provide the implementation for the MethodAccessController
interface. Each delegate gets it's own MethodAccessController object
(during construction) which has been designated a Permission to check (at
construction time), from the policy. The MethodAccessController
implementation will have to keep a static set internally of all objects, the
policy will require a static method to Enumerate over these and set them to
check when the Permission Class matches that of a revoked Permission,
probably by passing a Set of Classes.
This Permission check would be optimised, to call
AccessController.checkPermission(Permission) only under the following
conditions.
1. If this is the first time the current thread has called a method
(or constructor) on the delegate object.
2. If revocation has occurred for a Permission with the same Class in
any ProtectionDomain, since the last permission check performed on
that thread. The MethodAccessController keeps track of the
threads with an object weak hash map.
The $1,000,000.00 question: Is the optimisation of only checking a thread
once, on the assumption that if the ProtectionDomain's on that thread's
stack are trustworthy to access the method, the code involved in this thread
can still be trusted until a Permission that implies it has become revoked?
Remembering that the code was originally trusted, the object constructed
with the Permission check performed, utilised by that code for a period of
time, but now now that Permission has been revoked any method called on the
delegate throws an AccessControlException.
The only way the code could still have the Permission is if the
ProtectionDomain doesn't exist on the thread's stack, at the time of the
permission check, the check field is cleared for that thread and later, the
thread invokes the method with the ProtectionDomain in question on it's
stack, however to do so, the code in question must already hold a reference,
but not be involved in the current operations, it seems the probability
would be very low, the reference would have to be passed from another
thread, if an attacker could place this in the code, they'd be better off
attacking during the privileged period. The Permission revoked code would
stop privileged operations during re verification of trust for another proxy
object and server.
Static fields within the code could be used to store information between
service proxy's, this has a parallel to applets, where this was fixed with
separate ClassLoader, the client has that option however.
Publicly shared proxy and service implementations can have their source
audited.
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?
Closed, to free the port. If somehow it is shared between threads, the
other thread will receive an IOException.
-Was a delegate introduced and where?
The best place is in a builder or factory method, since constructors create
a dependency link. I'm thinking of a implementing new Platform class or
builder for the various Stream classes, along with new Permission's
-Can the code use reflection to bypass the delegate?
Yes, if it has Permission.
-Is reflection denied generally?
Yes, it should not be granted to code that will have Permission's revoked.
Thanks,
Your welcome, & thanks for asking too ;)
Cheers,
Peter.
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.
