river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (trust)
Date Wed, 06 Oct 2010 00:58:49 GMT
Sim IJskes - QCG wrote:
> On 10/05/2010 01:07 PM, Peter Firmstone wrote:
>> Yes I think Sim is talking about making trust decisions and Michal and I
>> are talking about the handshake, we need both, I don't think we're
>> having an issue of agreement, just understanding.
> No, i'm talking about both.
> Before you can unmarshall, you need code. This code is loaded by a 
> classloader. The ONLY place where we can check code, is this classloader.
> For every trust decision i've made, the classloader should check if 
> what is loaded is consistent with the trust decision i've made.

Aha you want to sign the jar and prevent class loading of unsigned 

> I want this trust system to be exclusive. Only when trust is granted 
> am i willing to perform code i have been given.

Trust in our discussion's so far is based on the Subject of the 
Services, ie Principals, I've had trouble with this too, Fred Oliver 
helped me out.  The difficulty with signing the jar file and using it 
for the trust decision is, the CodeSource may be used by many, whom you 
may have different trust relationships with.

The DOS issue we're dealing with is outside the Java security system, no 
trust has yet been established or granted.

But yes, it would be possible to limit ClassLoading based on who has 
signed the code.

> I want this trust system to be dynamic. I want to be able to change my 
> mind.

Once you've loaded the class files, that's it, the ClassLoader will only 
become garbage collected when no strong references to objects and class 
files remain.  You've only got one shot at that decision.

Currently the Java Security Model is also a one choice trust decision, 
once you've granted trust, references to security sensitive objects 
escape, the policy is no longer consulted, security sensitive object 
references can leak into untrusted code, if we're not careful with our 
programming.  This is how you get a security exploit.  Li Gongproposed 
Security policy decision's being part of object implementation, rather 
than something external to the object.  To do this you create a suitable 
guard in an objects constructor, this guard is checked on every 
sensitive method invocation.

I'm working on trust revocation. I have a basic InternetSecurityManager, 
two Security Delegates (FileInputStream and FileOutputStream) and 
DelegatePermission's that represent another Permission but can be 
revoked because Security Delegates use Li Gong's Object Method Guard 
pattern.  The InternetSecurityManager caches the results of permission 
checks for each AccessControlContext, for rapid repeated checks.

> I want this trust system to be automated only in removing trust. I 
> dont want to have a machine surprise me by downloading a trojan.
> I want this system to be certification friendly. So not only based on 
> Principal alone.

If you have a look in my PermissionGrant implementation classes, I've 
made it programatically possible to require that a ProtectionDomain have 
Principal[]'s and it's CodeSource be signed by Certificate[]'s before 
the grant is allowed.

So for ultimate security there might be a public clearing house for 
review of code, compiled and signed by reputable developers after auditing.

A client might require Certificate[]'s as well as particular 
Principal[]'s, this would provide a maximum security environment.

While that's good and highly recommended, it might be too much to impose 
it on everyone.

I noticed that Maven provisioning and CodeSource caching has been 
brought up again, these are ideas I support, we could use some 
volunteers here, at the moment I'm on my own, I've had the 
StreamServiceRegistrar interface up for a while (now in pepe under 
org.apache.river.api.lookup) but haven't had any feedback.

At this stage I don't think we can envision eliminating dynamic code 
downloads in favour of Maven Provisioning, since this is still in 
gestation,  We need a URL schema we can use for Maven provisioning so we 
can obtain the maven URI from the proxy MarshalledInstance, and check we 
have the correct archive with the provided checksum, or deliberately 
specify another version.

Then we need an additional get() method that supplies our preferred 
CodeSource to the MarshalledInstance for unmarshalling the proxy.

It's important to remember a Service may change it's proxy 
implementation at any time, a client should never become dependent on a 
particular implementation.

We certainly have made progress with understanding dependency 
relationships between Service API, the service implementation, proxy and 
client.  If we make the ClassLoader inheritance hierarchy the same, then 
all the ClassLoader issues go away.

For two Services with different Subjects and identical CodeSource, we 
need two distinct separate ClassLoader instances,specifically for each 
Subject, so static class variables can't be shared between them and the 
trust decision for one Subject, doesn't apply to the other.

An applet get's it own ThreadGroup, ClassLoader and SecurityManager 
which captures System.exit() and only terminates the applet rather than 
the entire JVM.  The applet is still unmarshalled even if unsigned, but 
it is restricted to it's own thread group.

My intent was to restrict the proxy to a single Thread with a priority 
of about 4, with it's own UncaughtExeceptionHandler.  The proxy is 
restricted to this thread during unmarshalling.  Once the proxy has been 
unmarshalled and trust has been verified based on authenticating the 
Subject, the proxy can be safely executed on the client thread.  While 
the proxy is in quarantine, before trust is established, the client can 
only call it via a reflection proxy that places all method calls on a 
queue to be executed by the Quarantined Thread.  Because the proxy is 
not executing on the client thread, the client can't be taken down.  The 
proxy can only destroy itself.

If we do this, the attacker will have to instead attempt to fool the 
authentication mechanism and then do something nasty.

If we use public key certificates for Subject's identity, then any 
breaches of trust can be reported as bad feedback against these services 
and the unstrustworthy service will find itself isolated.

To me, fixing the DOS attack is simpler for Application developers and 
doesn't exclude adding the additional security benefits you're proposing 
and we're not increasing the initial learning curve required of 
application developers.


> Eh, would this constitute a requirements definition? :-)
> Gr. Sim

View raw message