Re: [equinox-dev] principal based permissions in osgi

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Thanks Ben,

I have found one thing that we need
to look into for the PermissionCollections that are created for bundle
classloaders by the framework.  Currently our implementation of the
PermissionCollection#elements is not returning permissions that are assigned
by conditional permissions.  It only returns any assigned permissions
from PermissionAdmin or if there are not any assigned then it returns the
default permissions.  The (default) default permissions are AllPermissions.
 This causes our PermissionCollection#elements to return an Enumeration
of AllPermissions even though the bundle really only has permissions that
are assigned by conditional permissions when they exist.

Under normal circumstances this is no
problem because PermissionCollection#elements is not used for permission
checks at runtime.  But as it turns out JAAS uses the PermissionCollection#elements
to setup the AccessControlContext for a Subject.  These permissions
are then used in combination with the permissions that are set for the
principal of the Subject.  The problem is we return AllPermissions
unless the default permissions in Permission Admin are set to some other
set of permissions.  This ends up granting Subjects more permissions
than what we would like.  It also circumvents our PermissionCollection#implies
method because the combined Subject's permissions already contain AllPermissions.
 As a result we never check the condition.  One possible solution
to this problem is to always return an empty Enumeration from PermissionCollection#elements.
 This would force our PermissionCollection#implies method to always
be called because the Subject's set of permissions would be empty.  This
way we get to evaluate our condition to see if the Subject meets our principal
condition and then can be granted the permission.

We never use the PermissionCollection#elements
method ourselves in checking permissions at runtime.  But I am wandering
what other implications such a change could have.  Is anybody else
aware of other uses for PermissionCollection#elements?  For example,
I already know that the PermissionCollection#toString uses it to print
the set of permissions in a collection.

Either way our implementation needs
to change.  Another option is to actually evaluate all the conditions
at the time of the PermissionCollection#elements call to figure out what
permissions are set to at that particular time.  This would be very
expensive because we would have to aggressively evaluate every condition/permission
set in the system.  Currently we do this lazily for each permission
type that is check.  Another problem with this approach is the fact
that this operation occurs during a permission check.  We would be
forced to do other permission checks within this permission check just
to figure out the set of permissions for a PermissionCollection.  This
may be hard to do.

Tom

Benjamin Reed <breed@xxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/17/2005 11:52 PM

Please respond to
Equinox development mailing list

To	equinox-dev@xxxxxxxxxxx
cc	Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Subject	Re: [equinox-dev] principal based permissions in osgi

Here is a patch to FrameworkSecurityManager and an
implementation of 
PrincipalCondition. Subject.doAsXXX() methods function as normal. Principal
to Permission bindings are done through ConditionalPermissionAdmin. For
example, a ConditionalPermissionInfo of the form:

[...BundleLocationCondition http://www.ibm.com/-]
[...PrincipalCondition SuperMan]
(java.security.AllPermission)

says that when classes from a bundle from www.ibm.com are run with SuperMan
set as the current Subject, they will have AllPermission.

Initial tests (thanx Pascal) indicate that it's working.

One thing (of many) to remember when playing with JAAS is that 
Subject.doAsXXX() is a glorified AccessController.doPrivileged(). The biggest
outcome is that a Subject (and it's principals) get associated with a new
 
AccessControlContext. A subtle effect of this is that if a doPrivileged
is 
done inside of a doAsXXX() the new AccessControlContext setup by the 
doPrivileged will lose the Subject.

The current AccessControlContext (ACC) can be extracted using 
SecurityManager.getSecurityContext(), passed around, and evaluated directly
using SecurityManager.checkPermission(Permission, Object). It is for this
reason that PrincipalCondition needs to get a reference to the ACC being
checked, since it may not be the same as the one returned from 
AccessController.getContext().

The attached patch adds a method for the PrincipalCondition to get the
ACC 
being evaluated so that we can get the Subject of correct ACC. Because
PrincipalCondition depends on a SecurityManager that has the added methods,
the implementation of PrincipalCondition is not portable (it cannot be
run on 
other OSGi implementations). It would be nice to standardize a way for
Conditions to get the ACC being evaluated. If in the future DomainCombiners
are used in other ways, corresponding conditions would also need the ACC.

ben

On Thursday 15 September 2005 12:00 pm, Pascal Rapicault wrote:
> Hi,
>
> Lately I've been looking at JAAS and its capability to dynamically
> associate permissions based on principals (usually declared in a policy
> file) and from that to use Subject.doAsPriviledged.
> Given that OSGi has its own way of expressing permissions, I would
like to
> understand how principal based permissions can be declared.
>
> Thank you,
>
> PaScaL
[attachment "FrameworkSecurityManager.patch" deleted by Thomas
Watson/Austin/IBM] [attachment "PrincipalCondition.java" deleted
by Thomas Watson/Austin/IBM] _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev