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: PAM - Pluggable Authentication Modules Any Ideas?
Date Tue, 18 May 2010 10:28:37 GMT
Hi Gregg,

Are you happy to donate the code from your http://pastion.dev.java.net 
project and upload it to JIRA?

JERI is quite pluggable, so I'm confident we can integrate it without 
getting tied to particular platforms and your code donation would be 
very appreciated!

It's both interesting and understandable that both yourself and Dennis 
are wary of remote code security, so I'll concede defeat on this 
occasion, I consider you both more experienced than I, that also means 
that if either of you feel the inclination, I invite you to please 
consider becoming Committers with Apache River.

However as a separate interest, I'm looking into what can be done about 
dynamically downloaded code and trust.

Currently when you install Apache River locally, you go to the Apache 
web site, download the release, it's signed using pgp and you can use 
asynchronous public key cryptography to confirm the file checksum.  I 
suppose a good DNS spoofing attack could destroy trust, if you didn't 
have a copy of my public key locally.

To me, cryptography is just as important to dynamically downloaded 
code.  Today md5 is considered weak, httpmd may no longer be considered 
trustworthy and is in need of a suitable replacement.

I'm working on a Concurrent replacement for DyanamicPolicyProvider, we 
have the ability to dynamically grant permissions to a particular 
ClassLoader with a set of Principals, OR a set of principals, OR a 
ClassLoader.  This is based around proxy trust.

I'm currently working on a new mechanism for storing permission grants 
and considerably expanding the flexibility of dynamic permission grants, 
to more faithfully replicate those of policy file permission grants and 
then some.

So I'm working on allowing dynamic grants (and revoke) by:

ProtectionDomain (only exists at runtime, multiple may exist per 
ClassLoader)
CodeSource (again multiple may exist per ClassLoader, in addition it can 
exist in multple ClassLoaders, many to many relationship)
Certificate[] - Certs used to sign code.

These are in addition to Principal[] and ClassLoader.

The underlying theory, is to allow permission by divide and conquer of 
trust concerns.

What can we do with the additional flexibility?

Well, for one, we'll be able to grant permissions based on the 
certificates of the developers we trust, this will allow for peer review 
of several companies or individuals that cooperate based on some common 
code, after it has undergone peer review, we might also want to combine 
this requirement with a particular set of Principals, who are allowed to 
execute that code.  Then this code will be considered safe for dynamic 
download, update (developer trust, integrity) and execution (developer 
and user trust must be satisfied).

You might want to revoke permissions based on a vulnerability discovered 
in a particular CodeSource, without revoking certificates, principals 
etc.  Or if a group of certificates have become compromised, revoke 
permissions specific to those.

I'd like to set up a Codebase where users can contribute their Service 
Interfaces, Apache River can distribute these on their behalf, after 
peer review. I'd like to create a runtime ClassLoader for Service 
Interfaces, high up in the ClassLoader hierarchy so proxy's and clients 
can cooperate using them.  By allowing ProtectionDomain based 
Principal[] permission grants, we can load codebase-less dumb proxy's 
with the Service Interface ClassLoader, this solves problems with 
ClassLoader visibility for non hierarchical ClassLoader relationships in 
some environments, such as OSGi, although developers might want more 
specific control of ClassLoader visibility, so don't take this as final.

Another benefit of ProtectionDomain based grants, a Service's smart 
proxy might utilise a trusted piece of code, it might provide access to 
a protected system resource.  This trusted piece of code can reside in 
the same ClassLoader with the proxy, visible only to the proxy and 
within it's own ProtectionDomain to perform some function on behalf of 
the proxy, without allowing whatever the secure concern might be, to 
escape via the proxy, or allowing the proxy itself to be privileged.  
This trusted piece of code could be based on a Certificate chain and 
Principal[] and have its permission revoked as soon as it is no longer 
needed.  Trust for that code might be negotiated between the two 
cooperating parties, or it might be posted for public peer review and 
signing.

Once we have this additional power and flexibility, then we can build 
infrastructure on top.

I believe we can create a new web environment in which people, equipment 
and computers can cooperate based on models of trust, encryption and 
dynamic code, utilising Apache River's Jini Services implementation.  Or 
we can die trying.

Come all ye developers, join in the fun, lets work together and get our 
River flowing.

Peter.







Mime
View raw message