Subtleties of JAAS in an internet djinn (was Distributed Network Security)

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

I'm going to raise this as an issue on Jira, however I want to be sure I 
haven't overlooked something first, so I've cc'd this to a number of 
you, I know many of you are busy, so won't be offended if you're unable 
to weigh in, if there are other reasons for not responding to the list 
please feel free to correct any of my assumptions directly.

In a djinn (Jini network environment) You can limit untrusted code from 
gaining permission by ensuring policy permission grants, include both 
the Principal && ( CodeSource URL || Signer) and by only granting 
trusted code AuthPermission("doAs").

But what if I want to run as a Subject with untrusted code?

To run as a Subject, you have to trust the code and it must have 
AuthPermission("doAs"), unfortunately, this allows the code to run as 
ANY subject, which may be undesirable, if "doAs" is granted, there are 
no restrictions as to which Subject the code may run as, including an 
administrator if it finds itself on the stack at the right time, this 
might allow code to perform a privilege escalation attack.

To allow a user to execute some task via a smart proxy service, 
AuthPermission("doAs") must be granted to the smart proxy after 
verifying proxy trust.

But what if we want to use a service with a smart proxy without granting 
trust?  So I can use it while running as my Subject, allowing me to use 
my public credentials for authorisation to run as my Subject on the 
services server (with another set of Principals assigned by the service 
server), without granting smart proxy code my local Principal 
Permissions from my local domain. I want to allow Subjects to cross 
authority domains (personal, company and country network boundaries), 
where trust relations aren't implicit.

Under certain circumstances in a dynamic distributed environment like 
River; we don't always know in advance who the code Signers will be or 
which CodeSource URL will be utilised (which is why we have 
DynamicPolicy; the server Subject vouches for the proxy code).

For example, if you provide a collaboration service (via the internet), 
which utilises handback objects from clients (a handback object could be 
another service proxy), when client Subjects log in to use the service, 
there is a risk that another clients code is on the stack at the time 
Subject.doAs is called, enabling it to access information that is only 
intended for the user that has just logged in, by Subject.doAs injecting 
it with the another users principals and running on the another users 
thread, in doing so the ProtectionDomain on the new user thread call 
stack no longer contains the original Subject's Principals, but now only 
the new user / Subject's Principals.

This issue is specific to Jini / River because of the power of dynamic code.

Although this power isn't fully utilised now, it may be in the future, 
if Jini services are made available on the internet.

One solution might be to add methods similar to Subject's static methods 
to net.jini.security.Security.

As I mentioned earlier (see Re: Distributed Network Security), we could 
extend and modify SubjectDomainCombiner to add a SubjectProtectionDomain 
to the call stack, instead of adding Principals (privileges) to all 
ProtectionDomains on the stack at that point in time.  This way we no 
longer need to check for AuthPermission("doAs") and untrusted code is 
prevented from performing a privilege escalation attack if it exists on 
the call stack at the time another user Security.doAs(Subject, 
PrivilegedAction) is called.

There are other subtle kinks with SubjectDomainCombiner (implementation):

When an administrator adds or removes a Principal from a Subject, the 
ProtectionDomains on the stack are not updated, this requires a user to 
complete the PrivilegedAction before changes are effected.

If we have SubjectProtectionDomain and add it to the call stack, we 
don't need to add Principals to every ProtectionDomain, instead the 
SubjectProtectionDomain asks the Subject for the Principals.  This 
allows dynamic updates to be effected immediately, without requiring the 
user to log out and in again.  Implementing equals and hashCode in 
SubjectProtectionDomain would no longer require caching of 
ProtectionDomain instances too.

Each domain is responsible for assigning Principals to Subjects, 
Subjects may have different Principals in different domains.

It's worth noting that Oracle has been fixing deserialisation privilege 
escalation attacks, when downloaded code doesn't yet appear on the call 
stack and privilege escalation attacks by classes that extend trusted 
classes, but don't override their methods allowing them to avoid 
appearing on the call stack.

We can use similar methods to limit privileges during proxy class 
initialisation during unmarshalling in MarshalledInstance.

I propose adding the following static methods to net.jini.security.Security:

   public static <T> T doAs(final Subject subject,
            final PrivilegedAction<T> action) {
        throw new UnsupportedOperationException("not implemented");
    }
   
    public static <T> T doAs(final Subject subject,
            final PrivilegedExceptionAction<T> action)
            throws PrivilegedActionException {
        throw new UnsupportedOperationException("not implemented");
    }
   
    public static <T> T doAsPrivileged(final Subject subject,
            final PrivilegedAction<T> action,
            final SecurityContext context) {
        throw new UnsupportedOperationException("not implemented");
    }
   
    public static <T> T doAsPrivileged(final Subject subject,
            final PrivilegedExceptionAction<T> action,
            final SecurityContext acc)
            throws PrivilegedActionException {
        throw new UnsupportedOperationException("not implemented");
    }

Where SecurityContext is determined by calling Security.getContext().  
SecurityContext contains the AccessControlContext in addition to any 
other context settings, like the context ClassLoader.

We would require a Security Property to be set to allow these methods to 
behave identical to existing JAAS Subject static methods OR to behave as 
proposed.

// Security Property
String subjectBehaviourProperty = 
"net.jini.security.Security.distributed_domain_subjects";

DynamicPolicy grants would also need to subtly change the way 
Security.grant methods operate when the property is true, both the proxy 
ClassLoader and the Principal must be granted necessary permissions 
separately as they will appear in separate ProtectionDomains in the 
active AccessControlContext.

DistributedSubjectDomainCombiner would extend SubjectDomainCombiner and 
effect the required changes, only one SubjectProtectionDomain would 
exist on the stack at any time.

Compatibility would be maintained with existing JAAS providers etc.

Policy files may need to be written a little differently to reflect the 
separation of concerns of Principal and CodeSource permissions.

Penny for your thoughts?

Best Regards,

Peter Firmstone.

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

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

Peter Firmstone wrote:
>
>   3. In Jini security documentation I've seen on the web,
>      Subject.doAsPrivileged is called with a null AccessControlContext
>      executing the proxy, in doing so the proxy PD is no longer on the
>      stack, however it isn't clear when the proxy ProtectionDomain will
>      be added back onto the stack, will it be possible for an object to
>      be deserialised in a privileged context?  It's highly possible,
>      because of delayed class loading.
This statement isn't correct, the inherited domains are still included 
on the stack, which includes the proxy provided that 
AccessController.doPrivileged method hasn't been called first.  If the 
proxy's PD is on the stack during the Subject.doAsPrivileged call, it 
needs to have AuthPermission("doAsPrivileged"), which is undesirable.  
The risk of deserialisation in a privileged context still exists 
however, if a domain with minimal Privileges isn't on the stack during 
deserialisation.

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

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

Thanks Gregg,

The services you deploy are often unique, but relevant and it's apparent 
you've been able to explore and delve deeply into complex problems.  I'm 
grateful that both you and Dan are finding some time to discuss this 
issue, because to be quite honest, I'm not happy that I fully grasp the 
issues myself and discussion helps to improve understanding.

You've also hit the nail on the head, it's about limiting permission 
while executing as a Subject while further limiting permissions 
available to the proxy, but still allowing the Subject to have more 
permission when the proxy isn't on the call stack. 

It was also about separating Principal and CodeSource concerns, so you 
don't need to ensure that all your policy grant files include CodeSource 
and Principals.  - But it turns out that this isn't necessary there is 
an alternative option that follows:

Dynamic grants made to proxy's usually include the CodeSource and 
Principals, in the current case, the permission granted can be less than 
with the same Principals executed only in the presence of signed trusted 
code, the dynamic grant is very specific, to be granted permission the 
code must have the proxy ClassLoader and be executed by a Subject with 
the Principals specified in the grant.

If the proxy doesn't have AuthPermission("doAs"), get the current 
context by calling AccessController.getContext() this will contain the 
proxy's ProtectionDomain if it has already been unmarshalled, then use 
AccessController.doPrivileged to execute Subject.doAsPrivileged(Subject, 
PrivilegedAction, AccessControlContext), which injects the Subject 
principals into the proxy codebase, without allowing the proxy to gain 
the privileges the Principals have in the presence of trusted signed code.

Rather than modify SubjectDomainCombiner, the alternative option 
described above works by signing all your local code (some additional 
work for the developer) and all Principal based grants must also include 
signed by, so those principal grant's can't be stolen by untrusted code, 
because untrusted code it isn't signed with the Certificates stated in 
the policy file.  No grant should be made to a Principal alone, it must 
include a CodeSource URL or a jar Signer.  BTW, ConcurrentFilePolicy 
uses CodeSource URI's not URL, a small change of semantics for a big 
performance gain.

Another benefit of signed code is it protects local package private 
security boundaries, of course this will create more errors if you 
haven't got your preferred lists right.

So we could provide two additional methods in 
net.jini.security.Security, but without modifying SubjectDomainCombiner, 
while also preserving current policy behaviour, to ensure that the 
AccessControlContext used in Subject.doAsPrivileged is not null.

I guess what I've also just shown is that granting to a combination of 
CodeSource / Signers and Principals is determinate as Dan mentioned in a 
previous post, so yes, Dan was right.

Do you think a practical way for an administrator to limit the 
Permissions a Subject can grant to a service proxy is by limiting them 
with GrantPermission?  It allows the Subject to have more permission (in 
the presence of trusted signed code) than it's capable of granting.

The proxy could make available a list of Permissions it needs within the 
jar file as you've suggested.

My gut feel is permissions should be granted by the Subject to the proxy 
(in the presence of trusted code), however since not all Subjects are 
people, this mechanism needs to be flexible.  Any ideas? Events?

We can also determine if a Subject can grant a subset of the Permissions 
requested by the proxy, by creating a ProtectionDomain that contains the 
Principals and required Signer Certificate (this won't work for 
CodeSource URL's only signed code), then ask the Policy for it's 
PermissionCollection, then check GrantPermission for each permission on 
the list.

This is where things get a little interesting, since 
Subject.doAsPrivileged or Subject.doAs can be used to perform the 
dynamic grants, there are traps for the uneducated.

Privileged context must not be used as the context to communicate with 
the proxy itself, so it's beneficial to developers if we provide the 
methods to perform high risk tasks without requiring the proxy to have 
AuthPermission("doAs").  Prior to receiving dynamic grants, the proxy, 
even if injected with Principals does not have Principal privileges, 
hence privilege escalation is impossible, provided all grants to 
principals also require a trusted jar signer.  We can even pass the 
proxy class to these methods, so they can ensure the proxy's 
ProtectionDomain is on the stack, prior to making any method calls to 
avoid deserialisation attacks.

Some supporting information:

   1. Deserialisation Attacks: During deserialisation, there is a small
      time period during class loading where privileges must be
      minimised. Deserialisation privilege escalation attacks rely on
      deserialisation being performed in a privileged context while the
      ProtectionDomain of the object being deserialised is not yet on
      the stack.  Google deserialisation attacks if you're interested. 
      We should also add a PD with restricted privileges to the stack
      while MarshalledInstance performs unmarshalling, just to make sure
      that all deserialised object have no more privileges than required.
   2. Thankfully this bug has been recently fixed:
      http://slightlyrandombrokenthoughts.blogspot.com.au/2010/04/java-trusted-method-chaining-cve-2010.html
   3. In Jini security documentation I've seen on the web,
      Subject.doAsPrivileged is called with a null AccessControlContext
      executing the proxy, in doing so the proxy PD is no longer on the
      stack, however it isn't clear when the proxy ProtectionDomain will
      be added back onto the stack, will it be possible for an object to
      be deserialised in a privileged context?  It's highly possible,
      because of delayed class loading.
   4. N.B. I'm not talking about denial of service during unmarshalling,
      where the attacker is simply of nuisance value, say running an
      unending loop or using up all memory.  In this case the user can
      just kill the jvm and start again.  No deserialisation attacks can
      allow creating ClassLoaders or setting the SecurityManager in
      privileged context.

Solution:

Always ensure a domain with minimal privileges exists on the stack 
during deserialisation.

Cheers,

Peter.

Gregg Wonderly wrote:
> On Jul 7, 2012, at 8:02 AM, Peter Firmstone wrote:
>
>   
>> These doAs methods in this case cannot elevate Permission, they can reduce Permission to that which the Subject has in common with other code on the stack, but it cannot be used by code to gain privilege if it uses a custom DomainCombiner that extends SubjectDomainCombiner.
>>
>> Would this be an acceptable compromise?
>>
>> In future, we can look at other tools to assist with simplifying security, such as static bytecode analysis or FindBugs perhaps.
>>     
>
> When I am using remote code, I either trust it by source, or don't, and can assert that trust by granting AllPermission for the URL, or not.  Adding local resource access to a proxies code base, is usually limited to network access, but sometimes file access for certain UIs which, for example, have images which my caching URLHandler will store on disk.  That access to local resources, whether through Subject grant, or blanket permission is what matters for using a services ServiceUI.  When I use a services proxy for interaction, I've always used JAAS login services to gain access, via PAM login services on Linux and other PAM supporting OSes using JNI mechanisms.  Thus, there is a Subject created which has a set of Principals that my LoginModule creates in the form of a "user" and any "groups" that the user is a member of.
>
> In the services, I always use Subject.doAs with those subjects, and could use user or group based permission grants in my policy.  But, in the end, I never found that to be needed, and I instead, grant permissions to the codebase at the appropriate granularity (never granting to or using a client side codebase jar).
>
> The authorization framework that I've mention here, before, is then used to do role based control of how the API is used on the server, by the calls into that environment from the client.  I have a InvocationHandler that I insert to do the Subject.doAs() on the server side.  So, when the user authenticates with the server, I get a Subject.  I do Subject.doAs() to create an instance of the InvocationHandler (which holds a reference to the Subject), and the exported smart proxy instance, which is returned to the client.
>
> When a Subject asserts some kind of client local controls, it could provide some new functionality as you illustrated. In the case of network access control, or other local resource access, it could allow you to limit access to those resources, or to extend access in particular ways with a dynamic policy grant, on the client.
>
> I crafted some code in that direction at one point.  It allowed the jar to have a list of permissions in it, that it wished to have granted, and I was trying to decide what the right interface would be, to allowing the client software to talk to the user about these permissions.  In a sense, this was along the lines of Java WebStart kinds of thoughts.  My ServiceUI desktop has a code flow at the point that the UI is activated, that it could obviously do a resource query into the jar, find the requested accesses, and prompt the user to grant them.
>
> Conversely, you want to limit permissions by asserting a domain controlled by the Subject, that would provide whatever access you granted to the Subject in that domain/policty.  So, at the time that a client UI is first activated, you could use information about it being an uncontrolled codebase to trigger the assertion of the Subject controlled domain.
>
> What I think we need to focus on, are these two mechanisms (grant to client thread/Subject jar requested permissions and limit of client thread to already asserted Subject based domain) and the obvious fact that it's really about asserting control into the client execution environment.  We need to work on how we'd decide that needed to happen, and then think about whether it's just Subjects we want to assert, and whether we need to include the Privileged forms or not.
>
> Gregg Wonderly
>   

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

[Gregg Wonderly <ge...@cox.net>]

On Jul 22, 2012, at 5:04 AM, Peter Firmstone wrote:

> Since Gregg hasn't utilised traditional jvm style Permissions for Principals, there is no possibility of elevating privileges when calling Subject.doAs, so granting "doAs" to untrusted code doesn't present any security risk in Gregg's use case.

Just to make it clear, I do this precisely because the JVM permissions and principals with SecurityContext and all the other details are horribly complex for a developer and deployer to evaluate.  It becomes very problematic over the lifetime of a deployment to know when someone maybe calling from a new context that requires a specific security configuration to confine a use case to some limited set of permissions.

Practically, I just don't see the value in that.  I'd rather write utility methods, and call them from validated contexts with only the single entry point to validate.  The Apple world drove security down the path it went, because there was no "authentication" possible, at first, and then when signed jars were added, the code source, not the user was responsible for declaring it's intent.

My PAM login module uses password access in my applications.  My customers use a product that provides PAM access to the Windows directory services for authentication.  So there is no local administration of that, on the servers.  

> Also it's worth noting the Policy implementation can provide support, so changes to Subject Principals are effective immediately, leading to a much more programmer friendly JAAS.

I think that this security stuff, is a fairly large reason why Jini becomes overwhelming so quickly.  The simple fact that XXX.doAS and the security manager are never part of general Java programming education makes their introduction into the thought process very problematic.

Gregg Wonderly

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

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

Gregg Wonderly wrote:
> On Jul 7, 2012, at 8:02 AM, Peter Firmstone wrote:
>
>   
>> These doAs methods in this case cannot elevate Permission, they can reduce Permission to that which the Subject has in common with other code on the stack, but it cannot be used by code to gain privilege if it uses a custom DomainCombiner that extends SubjectDomainCombiner.
>>
>> Would this be an acceptable compromise?
>>
>> In future, we can look at other tools to assist with simplifying security, such as static bytecode analysis or FindBugs perhaps.
>>     
>
> When I am using remote code, I either trust it by source, or don't, and can assert that trust by granting AllPermission for the URL, or not.  Adding local resource access to a proxies code base, is usually limited to network access, but sometimes file access for certain UIs which, for example, have images which my caching URLHandler will store on disk.  That access to local resources, whether through Subject grant, or blanket permission is what matters for using a services ServiceUI.  When I use a services proxy for interaction, I've always used JAAS login services to gain access, via PAM login services on Linux and other PAM supporting OSes using JNI mechanisms.  Thus, there is a Subject created which has a set of Principals that my LoginModule creates in the form of a "user" and any "groups" that the user is a member of.
>
> In the services, I always use Subject.doAs with those subjects, and could use user or group based permission grants in my policy.  But, in the end, I never found that to be needed, and I instead, grant permissions to the codebase at the appropriate granularity (never granting to or using a client side codebase jar).
>
> The authorization framework that I've mention here, before, is then used to do role based control of how the API is used on the server, by the calls into that environment from the client.  I have a InvocationHandler that I insert to do the Subject.doAs() on the server side.  So, when the user authenticates with the server, I get a Subject.  I do Subject.doAs() to create an instance of the InvocationHandler (which holds a reference to the Subject), and the exported smart proxy instance, which is returned to the client.
>
> When a Subject asserts some kind of client local controls, it could provide some new functionality as you illustrated. In the case of network access control, or other local resource access, it could allow you to limit access to those resources, or to extend access in particular ways with a dynamic policy grant, on the client.
>
> I crafted some code in that direction at one point.  It allowed the jar to have a list of permissions in it, that it wished to have granted, and I was trying to decide what the right interface would be, to allowing the client software to talk to the user about these permissions.  In a sense, this was along the lines of Java WebStart kinds of thoughts.  My ServiceUI desktop has a code flow at the point that the UI is activated, that it could obviously do a resource query into the jar, find the requested accesses, and prompt the user to grant them.
>
> Conversely, you want to limit permissions by asserting a domain controlled by the Subject, that would provide whatever access you granted to the Subject in that domain/policty.  So, at the time that a client UI is first activated, you could use information about it being an uncontrolled codebase to trigger the assertion of the Subject controlled domain.
>
> What I think we need to focus on, are these two mechanisms (grant to client thread/Subject jar requested permissions and limit of client thread to already asserted Subject based domain) and the obvious fact that it's really about asserting control into the client execution environment.  We need to work on how we'd decide that needed to happen, and then think about whether it's just Subjects we want to assert, and whether we need to include the Privileged forms or not.
>
> Gregg Wonderly
>   
I've spent some time pondering the issue of running as a Subject in the 
presence of untrusted code.

I've realised that the Privileged forms are also required, to allow a 
context to be saved and run in an executor thread as an example.  But 
since Jini Security also allows preservation of the context ClassLoader 
or anything else for that matter, by utilising a Policy or 
SecurityManager that implements SecurityContextSource, I'd like to use 
SecurityContext in place of AccessControlContext.  
AggregatePolicyProvider implements it to preserve the context class 
loader.  Other than SecurityContext, the functionality would be similar 
to Subject.doAsPrivileged.

It is possible using the existing Subject.doAsPrivileged methods, to get 
the current context, then from within a privileged action call 
Subject.doAsPrivileged with the context previously retrieved.  In this 
case the Subjects Principals are only injected into the privileged 
domain of the calling code, excluding domains from the previously 
retrieved context.  The issue is of course when a trusted domain calls 
Subject.doAsPrivileged, it may already have AllPermission or have 
privileges, so additional principals are unlikely to grant additional 
privilege.  If there is untrusted code in assignedDomains, it won't 
cause security issues, since the Principals are not injected into 
assigned or inherited domains, only the current context, which in this 
case will be the privileged callers domain.

Available privileges are limited to the intersection of Permissions in 
each domain, if only trusted code is present on the Thread stack, the 
only way to restrict permission of the Subject will be to restrict 
permission of trusted privileged code.  This is however complex and 
difficult for developers to comprehend.  Separation of concerns between 
Principals and CodeSource is easier to comprehend.  Rather than grant to 
CodeSource and Principals, make separate grants for each, this ensures 
that a Subject has no more privileges than specified by grants to that 
Subjects Principals.

Many Jini services also use Subject.doAsPrivileged, to start a service 
with only one ProtectionDomain on the stack, injected with Server 
Principals.

Since Gregg hasn't utilised traditional jvm style Permissions for 
Principals, there is no possibility of elevating privileges when calling 
Subject.doAs, so granting "doAs" to untrusted code doesn't present any 
security risk in Gregg's use case.

The proposed doAs methods don't elevate privileges, on the contrary they 
may narrow privilege and hence aren't a security risk if called in the 
presence of untrusted code, unlike Subject.doAs, which will throw a 
SecurityException.

Providing an alternative to Subject.doAs would also be useful in the 
case where a service allows clients to hand back another remote object, 
allowing remote code (to which we don't want to grant privilege) to run 
on the server, while multiple client Subjects (represented by threads) 
interact with each other in the presence of untrusted proxy code in the 
same jvm.

But we must always be very careful not to deserialise in a privileged 
context, regardless of whether the new methods are used, otherwise 
DownloadPermission can be easily circumvented.

The use case here is for Internet based services, we need to assure 
administrators that running downloaded code is no less secure than using 
a web browser, otherwise an administrator would likely disable the 
functionality.

I'll commit an example implementation shortly, this may be removed in 
future, but it might be useful in explaining what I'm trying to achieve.

Also it's worth noting the Policy implementation can provide support, so 
changes to Subject Principals are effective immediately, leading to a 
much more programmer friendly JAAS.

Regards,

Peter.

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

[Gregg Wonderly <gr...@wonderly.org>]

On Jul 7, 2012, at 8:02 AM, Peter Firmstone wrote:

> These doAs methods in this case cannot elevate Permission, they can reduce Permission to that which the Subject has in common with other code on the stack, but it cannot be used by code to gain privilege if it uses a custom DomainCombiner that extends SubjectDomainCombiner.
> 
> Would this be an acceptable compromise?
> 
> In future, we can look at other tools to assist with simplifying security, such as static bytecode analysis or FindBugs perhaps.

When I am using remote code, I either trust it by source, or don't, and can assert that trust by granting AllPermission for the URL, or not.  Adding local resource access to a proxies code base, is usually limited to network access, but sometimes file access for certain UIs which, for example, have images which my caching URLHandler will store on disk.  That access to local resources, whether through Subject grant, or blanket permission is what matters for using a services ServiceUI.  When I use a services proxy for interaction, I've always used JAAS login services to gain access, via PAM login services on Linux and other PAM supporting OSes using JNI mechanisms.  Thus, there is a Subject created which has a set of Principals that my LoginModule creates in the form of a "user" and any "groups" that the user is a member of.

In the services, I always use Subject.doAs with those subjects, and could use user or group based permission grants in my policy.  But, in the end, I never found that to be needed, and I instead, grant permissions to the codebase at the appropriate granularity (never granting to or using a client side codebase jar).

The authorization framework that I've mention here, before, is then used to do role based control of how the API is used on the server, by the calls into that environment from the client.  I have a InvocationHandler that I insert to do the Subject.doAs() on the server side.  So, when the user authenticates with the server, I get a Subject.  I do Subject.doAs() to create an instance of the InvocationHandler (which holds a reference to the Subject), and the exported smart proxy instance, which is returned to the client.

When a Subject asserts some kind of client local controls, it could provide some new functionality as you illustrated. In the case of network access control, or other local resource access, it could allow you to limit access to those resources, or to extend access in particular ways with a dynamic policy grant, on the client.

I crafted some code in that direction at one point.  It allowed the jar to have a list of permissions in it, that it wished to have granted, and I was trying to decide what the right interface would be, to allowing the client software to talk to the user about these permissions.  In a sense, this was along the lines of Java WebStart kinds of thoughts.  My ServiceUI desktop has a code flow at the point that the UI is activated, that it could obviously do a resource query into the jar, find the requested accesses, and prompt the user to grant them.

Conversely, you want to limit permissions by asserting a domain controlled by the Subject, that would provide whatever access you granted to the Subject in that domain/policty.  So, at the time that a client UI is first activated, you could use information about it being an uncontrolled codebase to trigger the assertion of the Subject controlled domain.

What I think we need to focus on, are these two mechanisms (grant to client thread/Subject jar requested permissions and limit of client thread to already asserted Subject based domain) and the obvious fact that it's really about asserting control into the client execution environment.  We need to work on how we'd decide that needed to happen, and then think about whether it's just Subjects we want to assert, and whether we need to include the Privileged forms or not.

Gregg Wonderly

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

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

Hmm,

Very eloquently put, you describe typical corporate IT behaviour, I 
can't refute that.

In most if not all cases Subject.doAs is executed only in the presence 
of trusted code or code assumed trusted.

And yet, I'd like to have the ability to run as a Subject with less 
trusted code, call it an itch to scratch, if you like.

The code in question is not completely untrusted, it's partly trusted, 
written by another company for collaboration, but not trusted enough to 
grant AuthPermission("doAs") locally.

Perhaps if I narrowed it down only to two new methods, and no property 
to set, it might not seem as big a burden to carry:

    public static <T> T doAs(final Subject subject,
            final PrivilegedAction<T> action)
   
    public static <T> T doAs(final Subject subject,
            final PrivilegedExceptionAction<T> action)
            throws PrivilegedActionException

When I think about it, the doAsPrivileged methods aren't really 
required, because all I'd like to do in this case, is run as the 
Subject, without having to grant AuthPermission "doAs".   However I'd 
like to run as a Subject with the SecurityContext returned by 
Security.getContext(), rather than the AccessControlContext alone.  I'd 
like to allow the Subject to be authorised by the Service, for access 
control on the server, without granting much permission locally.

These doAs methods in this case cannot elevate Permission, they can 
reduce Permission to that which the Subject has in common with other 
code on the stack, but it cannot be used by code to gain privilege if it 
uses a custom DomainCombiner that extends SubjectDomainCombiner.

Would this be an acceptable compromise?

In future, we can look at other tools to assist with simplifying 
security, such as static bytecode analysis or FindBugs perhaps.

Regards,

Peter.

Dan Creswell wrote:
> "But what if we want to use a service with a smart proxy without granting
> trust?  So I can use it while running as my Subject, allowing me to use my
> public credentials for authorisation to run as my Subject on the services
> server (with another set of Principals assigned by the service server),
> without granting smart proxy code my local Principal Permissions from my
> local domain. I want to allow Subjects to cross authority domains
> (personal, company and country network boundaries), where trust relations
> aren't implicit."
>
> "Penny for your thoughts?"
>
> >From experience, where security really matters seemingly trust relations
> aren't implicit. There are long discussions about ensuring that a user of a
> service is who they say they are so they can be billed (amongst other
> things). Discussions extend further to SLA's, load that is acceptable,
> responses that are acceptable etc.
>
> In cases where security doesn't matter it's often a case of "buyer beware".
>
> Banks will often go as far as to bring in and certify particular .jars and
> not sanction any use of any other .jar or sourcing of code from e.g. an
> external maven repository.
>
> So, whilst we could support all these bits and pieces of security, I'm not
> sure of the value. It might allow a great deal of flexibility, all sorts of
> options but maybe the world-at-large doesn't need them because the way it
> deals in security is rather more polarised? And supporting all these
> different options makes verification that security is, in fact, maintained
> and not open to compromise ever more challenging.
>
> I'm still left with a feeling that says "if people want co-operation in a
> secure environment, they will take the simplest means possible to create
> enough security and no more". Which means virtual networks, firewalls,
> VPNs, static validation of code, certificates etc.
>
> Or put another way, for all but a few security is an exercise in effort
> versus risk that comes down to "don't bother" or "secure everything to the
> finest detail". Where would untrusted code be acceptable in such a world?
>
>   

Re: Subtleties of JAAS in an internet djinn (was Distributed Network Security)

[Dan Creswell <da...@gmail.com>]

"But what if we want to use a service with a smart proxy without granting
trust?  So I can use it while running as my Subject, allowing me to use my
public credentials for authorisation to run as my Subject on the services
server (with another set of Principals assigned by the service server),
without granting smart proxy code my local Principal Permissions from my
local domain. I want to allow Subjects to cross authority domains
(personal, company and country network boundaries), where trust relations
aren't implicit."

"Penny for your thoughts?"

>From experience, where security really matters seemingly trust relations
aren't implicit. There are long discussions about ensuring that a user of a
service is who they say they are so they can be billed (amongst other
things). Discussions extend further to SLA's, load that is acceptable,
responses that are acceptable etc.

In cases where security doesn't matter it's often a case of "buyer beware".

Banks will often go as far as to bring in and certify particular .jars and
not sanction any use of any other .jar or sourcing of code from e.g. an
external maven repository.

So, whilst we could support all these bits and pieces of security, I'm not
sure of the value. It might allow a great deal of flexibility, all sorts of
options but maybe the world-at-large doesn't need them because the way it
deals in security is rather more polarised? And supporting all these
different options makes verification that security is, in fact, maintained
and not open to compromise ever more challenging.

I'm still left with a feeling that says "if people want co-operation in a
secure environment, they will take the simplest means possible to create
enough security and no more". Which means virtual networks, firewalls,
VPNs, static validation of code, certificates etc.

Or put another way, for all but a few security is an exercise in effort
versus risk that comes down to "don't bother" or "secure everything to the
finest detail". Where would untrusted code be acceptable in such a world?