Hey, I am glad that you got interested by this topic. Sadly due other duties I will have no time to write about this solution before mid of March. It's part of training session I prepare. My goal was to show "grant signed by" and "grant principal" constructions known from standard Java 2 security mechanism. Signed by was much easier to achieve since BundleSignerCondition is built-it in framework. A real question is - shouldn't PrincipalCondition be shipped by framework to cover all Java 2 security features?
After training I should get more time to work on blog entry/wiki page. Before - all necessary code is in place on github project. Feel free to use it as you wish. Permission entries using Principal condition allows Subject.doAs/doAsPrivileged access to look up services etc. Cheers, Lukasz Wiadomość napisana przez BJ Hargrave <hargr...@us.ibm.com> w dniu 18 lut 2013, o godz. 16:21: > Yes. Put your example on wiki.osgi.org. > > -- > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > hargr...@us.ibm.com > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > > From: Karl Pauls <karlpa...@gmail.com> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>, > Date: 2013/02/17 16:43 > Subject: Re: [osgi-dev] ConditionalPermissionAdmin and Principal > permission > Sent by: osgi-dev-boun...@mail.osgi.org > > > > Good. I didn't find the time to figure out what was going on but i was > assuming that it should work. Maybe you want to share a working example so > that others know how it can be done - I think the JAAS with CPM is not > trivial but interesting... > > regards, > > Karl > > > On Sun, Feb 17, 2013 at 2:24 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote: > After backing to specification and reading part about CPM from begining I've > found lots of tips which helped me to fix scenario. One from most important > statements I wasn't aware of is that CPM may override local permissions but > can not grant more than bundle wants. After all it works like a harm. Thank > you for asistance! > > Kind regards, > Lukasz Dywicki > -- > Apache Karaf Commiter > http://dywicki.pl > > Wiadomość napisana przez Łukasz Dywicki <luk...@dywicki.pl> w dniu 15 lut > 2013, o godz. 18:16: > > I've tried with Felix 4.0.3 and security 2.0.1 - still the same. I deployed > additional maven profile called karaf-2.3.0 which allows to build and deploy > whole project with same framework version as you given. > > -- > LD > > Wiadomość napisana przez Karl Pauls <karlpa...@gmail.com> w dniu 15 lut 2013, > o godz. 17:58: > > > > > On Fri, Feb 15, 2013 at 5:47 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote: > I use Felix 3.2.2 and Framework Security 1.4.2. > > That is very old - can you try with Felix 4.0.3 and security 2.0.1? > > regards, > > Karl > > Wiadomość napisana przez Karl Pauls <karlpa...@gmail.com> w dniu 15 lut 2013, > o godz. 17:45: > > > > > On Fri, Feb 15, 2013 at 4:59 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote: > After few hours more spent on CPM I may confirm - I don't blow JVM and > framework. That's small success. :-) I've put results of my work to github > (https://github.com/splatch/osgi-cpm) my repiles inline. > > The most confusing part for me is why conditional permissions must be cleared > every time? > > What does "cleared every time" mean exactly and what does conditional > permissions imply? > In activator of CPM administration module where I perform update I clear > permission table. I belive it's not a preffered solution since it may remove > other administration modules entries. Now it works, however with more than > one administration module it will cause problems. Wouldn't be easier if CPM > service would return only table of permissions previously put by bundle? > > > Why I need to also push java.security.AllPermission at the end > > At what end and where to? > If I will not put ALLOW java.security.AllPermission at the end of CPM update > I will start getting errors with lack of access in different parts of > framework. Maybe my access restrictions were to broad? > > - even if I have this granted in startup policy and > OSGI-INF/permissions.perm? From my understanding CPM should not affect > permissions granted by PermissionAdmin. > > I'm not sure I understand what you are saying here. There is some interplay > between CPM and PA but why are you using PA in the first place (and what has > that to do with OSGI-INF/permissions.perm)? > Possibly it's my missunderstanding of CPM or wrong restrictions range. > ALLOW { > [Condition] > (java.io.FilePermission "file.txt" "read") > } > DENY { > (java.io.FilePermission "file.txt" "read") > } > > Without ALLOW AllPermission simply crashes framework and other services which > tries to read disk. I learned that access rules must have exactly same > statements except condition statements. Also pushing condition without > BundleLocation/Signer condition is wrong idea. > > > My custom condition is executed, however I can not obtain subject. Also it's > not executed during execution of PrivilegedAction from security-test module. > > Hard to say without looking at what you are doing in more detail. Doing a > doPriv in the security-test might be the wrong thing to do. You need a > doPriv in the condition, not necessarily in the test… > Now you may check code and observe what's going on. I even put multiple > statements into test module: > * execute action without authentication > * execute with Subject.doAs > * execute with Subject.doAsPrivileged > > In all cases my custom permission is not executed to verify access. > Subject.doAsPrivileged gets simply full access and ignores CPM rules. Maybe > it's guilty of AccessController, I don't know. In fact doAs[Privileged] have > Subject instance and uses SubjectDomainCombiner. Looks that these checks are > non-framework aware. > > Are you using equinox? If so, that will not work as you are using the > AccessController directly. Try using the SecurityManager instead to check > access. In felix it should work with both. > regards, > > Karl > > Cheers, > Lukasz Dywicki > -- > Apache Karaf Commiter > http://dywicki.pl > > > Hi Lukasz, > > I must admit, I'm not sure I understand what you did so you might have to > explain it again. However, > > * OSGi-INF/permissions.perm has nothing to do with granting permissions. It > is only there to allow a bundle to limit the permissions it gets. > > * There is no standard policy file in OSGi (it only looks like that would > be the case in the spec) - If you want something like that you have to > write it yourself (or use the one I wrote for the security chapter in OSGi > in Action: > > http://code.google.com/p/osgi-in-action/source/browse/#svn%2Ftrunk%2Fchapter14%2Fcombined-example%2Forg.foo.policy > > ). > > * Assuming by "custom permission" you are talking about custom _condition_ > yes, it is somewhat tricky to trigger security checks inside a security > check. However, it should be possible - are you sure the code base of your > custom condition has enough permissions and you do whatever you do inside > doPriv blocks? You can find an example of a custom condition here: > > http://code.google.com/p/osgi-in-action/source/browse/trunk/chapter14/combined-example/org.foo.condition.ask/src/org/foo/condition/ask/AskUserCondition.java > > ). > > Finally, I admit that it is possible that the combination of custom > condition that uses JAAS to determine the current subject isn't possible > but that would be a bug in felix so we would need to take the discussion > there maybe. Otherwise, this is what i would try: > > Write a custom condition that does determine the current subject via JAAS > from inside a doPriv block when it is asked whether it is satisfied and > returns true if the subject equals the subject name given in the parameters > of the condition. > Create a policy file that has an ALLOW for this condition with the name of > the subject and the permissions that you want to give to it. > Put the condition on the classpath and start felix with the security > provider and the policy bundle installed and see if it works. > > > regards, > > Karl > > > Dear all, > I was looking for something similar to grant for given principal authorized > by JAAS login module in OSGi world. I thought that > ConditionalPermissionaAdmin (CPM) will be solution of my problems, however it > failed to cover the scenario. > > I have very simple code to test security layer using standard Java mechanism. > My JAAS configuration: > Unix { > com.sun.security.auth.module.UnixLoginModule required; > }; > > Policy configuration: > grant Principal com.sun.security.auth.UnixPrincipal "workshop" { > permission java.io.FilePermission "file.txt", "read"; > }; > > This example allows to open "file.txt" when JVM is launch by user "workshop". > There are many examples, where this may be used and unix principal is used > just because it doesn't have any external dependencies. With this kind of > configuration I may grant access to given permissions using given principal > (GroupPrincipal "admin" to administer bundle states for example). > > I launched my example under Felix 4.x with Felix Security 2.0.1. However, > what I have observed - seems that OSGI-INF/permissions.perm must have > following syntax: > (permissionClass "resource", "action") > > I had following OSGI-INF/permissions.perm file: > ALLOW { > [com.example.PrincipalPermission "admin"] > (java.io.FIlePermission "file.txt", "read") > } "read file by admin group" > > I have login module which is capable to verify user credentials and perform > authentication. My code is executed with Subject.doAsPrivileged(subject, > action, null). I haven't tried that with Equinox yet. > > Another thing is usage of AccessControllContext inside custom permissions - > it causes stack overflow (I use > Subject.getSubject(AccessController.getContext())). I don't know how to avoid > that since my custom permission must obtain Subject instance to obtain given > permissions but it doesn't have access to subject instance. I don't want hack > with ThreadLocals since it will break compability with JAAS layer used by > many libraries. > > Did you ever got something like this running with CPM? If so, please share > tips with me. > > Cheers, > Lukasz > -- > Apache Karaf Commiter > http://dywicki.pl > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
