Jini Spec of DyanamicPolicyProvider

[Peter Firmstone <ji...@zeus.net.au>]

I'm curious about an original design decision made in DynamicPolicyProvider.

Currently implies(PermissionDomain, Permission) is expanded to encompass 
all Permissions granted to a particular ClassLoader that satisfies a 
particular Principal[] array.

I'm curious about the reason for doing so, in my 
ConcurrentDynamicPolicyProvider implementation I chose to have 
permissions tied to a particular CodeSource or ProtectionDomain.

The two remaining qa tests that fail (all jtreg tests pass) are directly 
related to the spec for DynamicPolicyProvider.

GrantPrincipal.td
GrantNoPrincipalCase02.td

No services or anything functional fail, only the spec implementation.

A SecureClassLoader can have multiple CodeSources and 
ProtectionDomains.   There is no way of asking the ClassLoader for these.

Typically most Service proxy's are packaged in a single jar file, it 
seemed logical to me that someone might want to grant some permissions 
based on a CodeSource and it's Signers (developers) and additional 
permissions based on the Principals (user or node).

These might exist in separate ClassLoaders or ProtectionDomains.

Right now I'm thinking about changing my use of ProtectionDomain for 
ClassLoader, however this goes against my instincts.

The difficulty arises when I want to revoke permissions based on a 
codebase (a vulnerability in the code, the developers keys are still 
good though) and determining which ClassLoaders are using them.  Example 
of use: RemoteEvent from a trusted Principal advising of a CodeSource 
vulnerability that can be fixed with a simple Permission revoke on the fly.

It's very easy to remove grants based on CodeSource or PermissionDomain, 
a ProtectionDomain is unique to a particular ClassLoader, however the 
CodeSource may be loaded in multiple.

Is anyone using dynamic grants for multiple PermissionDomains (which 
logically means multiple CodeSource's too) in their proxy's?

If I change the spec, it doesn't look like much will break, but that's a 
pretty drastic measure.

The new implementation DynamicPolicyProvider uses pluggable SPI, so we 
could keep around a compatible implementation of the old behaviour in 
case of breakage.

Re: Jini Spec of DyanamicPolicyProvider

[Peter Firmstone <ji...@zeus.net.au>]

Peter Firmstone wrote:
>
> The two remaining qa tests that fail (all jtreg tests pass) are 
> directly related to the spec for DynamicPolicyProvider.

Minor qualification, no new failures in jtreg or qa tests other than 
those mentioned, there are tests not run due to missing suitably 
configured Kerberos Key Server and Squid Proxy.

Re: Jini Spec of DyanamicPolicyProvider

[Peter Firmstone <ji...@zeus.net.au>]

Actually the impact on revoke() isn't as bad as it seems, the 
ProtectionDomain can be used to retrieve the ClassLoader to check 
against implies() based on ClassLoader.

So both behaviours can be provided by perhaps using a System variable.

What are the consequences of narrowing the implies() to only check the 
PermissionDomain and not expand out to encompass all PermissionDomain's 
within a ClassLoader as is the current behaviour of DynamicPolicyProvider?

ClassLoaders are used as a cheap form of subprocess isolation, a 
ClassLoader that contained more than one ProtectionDomain might be 
utilised to package a known partially trusted, signed package from a 
codebase, along with a proxy with it's own untrusted codebase.   That 
trusted piece of code might be used privately by the proxy to perform 
some function that requires static variables, so cannot be shared with 
other proxy's.  That would allow you  to grant a permission to the 
partially trusted ProtectionDomain within the proxy's ClassLoader, via 
the a CodeSource grant.

In DynamicPolicyProvider's current form, the proxy would inherit the 
permissions of the trusted piece of code, the additional power of not 
granting the proxy trust at all, instead allowing it to bundle a trusted 
piece of code to perform a function in the same ClassLoader but in 
another ProtectionDomain, might solve any number of future problems, 
such as that experienced by Neuromancer with RemoteReference and proxy 
trust.

Cheers,

Peter.

Peter Firmstone wrote:
> I'm curious about an original design decision made in 
> DynamicPolicyProvider.
>
> Currently implies(PermissionDomain, Permission) is expanded to 
> encompass all Permissions granted to a particular ClassLoader that 
> satisfies a particular Principal[] array.
>
> I'm curious about the reason for doing so, in my 
> ConcurrentDynamicPolicyProvider implementation I chose to have 
> permissions tied to a particular CodeSource or ProtectionDomain.
>
> The two remaining qa tests that fail (all jtreg tests pass) are 
> directly related to the spec for DynamicPolicyProvider.
>
> GrantPrincipal.td
> GrantNoPrincipalCase02.td
>
> No services or anything functional fail, only the spec implementation.
>
> A SecureClassLoader can have multiple CodeSources and 
> ProtectionDomains.   There is no way of asking the ClassLoader for these.
>
> Typically most Service proxy's are packaged in a single jar file, it 
> seemed logical to me that someone might want to grant some permissions 
> based on a CodeSource and it's Signers (developers) and additional 
> permissions based on the Principals (user or node).
>
> These might exist in separate ClassLoaders or ProtectionDomains.
>
> Right now I'm thinking about changing my use of ProtectionDomain for 
> ClassLoader, however this goes against my instincts.
>
> The difficulty arises when I want to revoke permissions based on a 
> codebase (a vulnerability in the code, the developers keys are still 
> good though) and determining which ClassLoaders are using them.  
> Example of use: RemoteEvent from a trusted Principal advising of a 
> CodeSource vulnerability that can be fixed with a simple Permission 
> revoke on the fly.
>
> It's very easy to remove grants based on CodeSource or 
> PermissionDomain, a ProtectionDomain is unique to a particular 
> ClassLoader, however the CodeSource may be loaded in multiple.
>
> Is anyone using dynamic grants for multiple PermissionDomains (which 
> logically means multiple CodeSource's too) in their proxy's?
>
> If I change the spec, it doesn't look like much will break, but that's 
> a pretty drastic measure.
>
> The new implementation DynamicPolicyProvider uses pluggable SPI, so we 
> could keep around a compatible implementation of the old behaviour in 
> case of breakage.
>