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
