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
CodeSources.
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.
Regards,
Peter.
Eh, would this constitute a requirements definition? :-)
Gr. Sim
