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
