[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] principal based permissions in osgi


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