Meant to send this feedback earlier, but had a meeting :-). As far as whether or not JSPWiki should disregard JVM Policy all together, my vote would be Yes. My reasoning and feedback:
As a WebSphere Administrator in an Enterprise setting, gray area is always an issue. To reduce this area as much as possible, we write standards and policies around what applications can and can't do within our environment. Since we administer an infrastructure of 'someone elses' applications, we try to make those lines as hard as possible while remaining somewhat flexible (needs of the business and all that). This is especially critical in many of our environments, which may host multiple applications. As an Administrator, I may use policy files and security to govern what an application can do on my system. These configurations are usually generic to give me security but allow flexibility with deploying an application. These are normally files I do not want to customize on an application by application basis unless absolutely necessary. Fewer deviations from 'standard' means less for me to track and worry about. In this scenario I would do 1 of two things. * Expect the application to bundle and utilize jspwiki.policy locally in the deployment. * Put a jspwiki.policy on the system and have multiple Wiki's refer to that one. Even with my 'developer' hat on, I still wouldn't want the system policy to dictate access to my application resources. You never know what those crazy infrastructure guys are doing under the covers :-). Thanks again! Joseph Hobbs Lead Technology Architect Enabling Technologies : Technical Services Fifth Third Bank Phone : (513) 534-5908 Fax : (513) 534-3408 Email : [EMAIL PROTECTED] -----Original Message----- From: Hobbs, Joseph Sent: Tuesday, December 02, 2008 10:00 AM To: '[email protected]' Subject: RE: jspwiki.policy and java.policy Andrew, Interesting points. I appreciate you taking the time to explain it! I'll have to look further into the Security Manager stuff. I was under the assumption that it allowed unless enabled, but that's evidently not the case :-). WebSphere offers the ability to place policies at various levels (application, module, etc), which makes it nice. With that said, one downfall to WebSphere's support of these policies is that it does not support certain types (like Principal permissions) in certain areas. When I deploy a WAR file, WebSphere automatically generates a was.policy file and includes it in the EAR it builds for me at META-INF/was.policy. That policy does not provide any additional privileges from what I can tell. It's more of a template that I can fill in later with specific policies. grant codeBase "file:${application}" { }; grant codeBase "file:${jars}" { }; grant codeBase "file:${connectorComponent}" { }; grant codeBase "file:${webComponent}" { }; grant codeBase "file:${ejbComponent}" { }; I'll poke around some more and see what I can find. IBM does some weird stuff now and again, so I'm sure it's hidden in here somewhere! Joseph Hobbs Lead Technology Architect Enabling Technologies : Technical Services Fifth Third Bank Phone : (513) 534-5908 Fax : (513) 534-3408 Email : [EMAIL PROTECTED] -----Original Message----- From: Andrew Jaquith [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 02, 2008 12:40 AM To: [email protected] Subject: Re: jspwiki.policy and java.policy Joseph -- Nice detective work. The changes you made should be sufficient to solve the problem you observed. However, I do not fully understand the conditions that caused you to have the problem in the first place. I have not seen this problem before. But I have a few hunches about the cause. Background: The reason AuthorizationManager.checkStaticPermission() works the way that it does is to support the ability for JSPWiki deployers to define JSPWiki security policies across the entire JVM in a single policy. This is useful in those cases where more than one JSPWiki instance is running (for example, where multiple JSPWiki webapps are running in a web container). As you have observed from the source of checkStaticPermission(), we call AccessController.checkPermission() to check the "global" JVM policy before we check the local jspwiki.policy. What actually happens under the covers in the global case is that AccessController consults the Java security policy configured for the JVM. By default, this is JAVA_HOME/lib/security/java.policy. However, it can also be overridden by setting the java.security.policy system property when the JRE is first invoked. MOST web containers, including Tomcat, implement "Java 2 security" by setting -Djava.security.policy=someURL, and then starting the SecurityManager (which enforces the policy) when they start up. I believe WebSphere works this way too. What you might not fully appreciate is that Java 2 security polices are ALWAYS available, even if they are not always enforced by via the JVM SecurityManager. In other words, when we call AccessController.checkPermission, the JVM's security policy is still being checked, even though the SecurityManager is not running. This particular subtlety (you can perform policy checks without requiring a SecurityManager) isn't obvious from a casual reading of the Java security documentation, but nonetheless it does work. Now, according to your tests, AccessController.checkPermission() is ALWAYS allowing any permission that it's asked about. That can only happen for one reason: something has told the JRE to use a security policy that grants all privileges to everything via "grant { permission java.security.AllPermission; };" or something similar. That something is almost certainly WebSphere. In other words, your observation... > Since I don't have Java Security enabled on the JVM, the JVM-wide > policy will not deny ANY actions. ...is close, but not quite right. It's more accurate to say that the JVM-wide policy is ALLOWING all actions. That's not what the default java.policy does, so it's probably due to a policy that WebSphere has configured. You can verify this by checking JAVA_HOME/lib/security/java.policy. You'll see that the generic grant{} block does not grant java.security.AllPermission. But it does grant a few permissions, like java.util.PropertyPermission "os.name", "read". (Indeed, this is exactly why we used it as a dummy permission -- because it is always available, on all platforms and for all grantees.) --- Ok, so that should give you some clues about what is happening with WebSphere. If you do any more digging about what/how WebShere installs its default policy, I'd be curious to hear what you found. But the real question, prompted by your particular issue, is "do we need JVM-wide security policies any more?" I am not sure that we do, but I'd like to hear from the rest of the devs about this. Local security policies (implemented by LocalPolicy in 2.6) mostly eliminated the need to worry about JVM-wide policies for ~90% of deployers. If we did get rid of JVM-wide security policies, we'd probably want to do it in 3.0, rather than in 2.8. Regards, Andrew On Dec 1, 2008, at 6:37 PM, Hobbs, Joseph wrote: > I dug into this a bit deeper and think I finally got it working. > Again > I don't know the implications of making these changes overall, > though I > did run into 1 issue I had to work around :-). Feedback on these > changes would be appreciated. If they make sense, I would be happy to > submit them through JIRA. > > The first thing I did was comment out the policy check within > AuthorizationManager.checkStaticPermissions(). So > checkStaticPermissions() looked something like this: > > if( !m_useJAAS ) return true; > > Boolean allowed = (Boolean)WikiSession.doPrivileged( session, new > PrivilegedAction() > { > public Object run() > { > // We're not going to check the JVM-wide policy at all... > /* > try > { > // Check the JVM-wide security policy first > AccessController.checkPermission( permission ); > return Boolean.TRUE; > } > catch( AccessControlException e ) > { > // Global policy denied the permission > } > */ > > // Try the local policy - check each Role/Group and User > Principal > if ( allowedByLocalPolicy( session.getRoles(), permission ) > || > allowedByLocalPolicy( session.getPrincipals(), > permission ) ) > { > return Boolean.TRUE; > } > return Boolean.FALSE; > } > } ); > return allowed.booleanValue(); > > When I commented this out, testing showed that the local policy was > being applied as expected. With that said, I ran into an issue when > attempting to view my profile. Inspection of the logs showed this > entry: > > 2008-12-01 17:40:36,874 [WebContainer : 1] INFO > com.ecyrd.jspwiki.WikiContext JSPWiki:/et/ops/UserPreferences.jsp > JSPWiki:https://myhost/et/ops/UserPreferences.jsp - User testAuthor > has > no access - forbidden (permission=(java.util.PropertyPermission > os.name > read)) > > This struck me as odd that we'd be testing for a PropertyPermission > for > reading os.name. Digging through the source a bit more I came up with > the reasoning. Since we're assuming os.name will always be readable, > it's being used as the dummy permissions check by > WikiContext.requiredPermission(). Since I took the JVM policy out of > the loop, this check won't be allowed! Oops! > > To get around this issue, I actually created a DummyPermission > class. I > then updated WikiContext.DUMMY_PERMISSION to point to it instead of > using PropertyPermission(os.name, read). > > private static final Permission DUMMY_PERMISSION = new > DummyPermission("dummy"); > > After that, I updated checkStaticPermission() again and added the > following check ABOVE the existing Local Policy checks. > > // Is this a DummyPermission? if so, return TRUE! > if ( permission instanceof DummyPermission ) > { > return Boolean.TRUE; > } > > After doing this, the wiki started working as expected. I still have > testing to do so I can make sure I didn't break anything else, but the > results look promising so far. > > Joseph Hobbs > Email : [EMAIL PROTECTED] > > -----Original Message----- > From: Hobbs, Joseph > Sent: Monday, December 01, 2008 3:56 PM > To: 'JSPWiki-dev ([email protected])' > Subject: jspwiki.policy and java.policy > > Hi All! New to the list, but not to JSPWiki. I've been using it > internally for a few years, and just recently started digging into it > deeper. Good stuff! I did run into one issue that confused me, and I > was curious to get some else's take on it. > > I'm running IBM's WebSphere Application Server 6.1.0.15 running on AIX > 5.3 and JSPWiki 2.6.4. WebSphere is using an LDAP Registry and I also > have RSA's Cleartrust for Single Sign On configured within WebSphere. > I've been successful in getting everything working (even SSO) with > JSPWiki through Container Managed security. I was able to do all of > this through modification of some XML (web.xml) and > jspwiki.properties. > One note... I do NOT have Java 2 security enabled (this is critical > for > later). > > The issue I've run into relates to JSPWiki and how it handles > jspwiki.policy. Even though I've defined roles and the container is > providing them, I'm still an admin. No matter what I do, I've got > full > privileges. I can do anything an admin does, even though I don't have > the privileges per jspwiki.policy. Page ACL's don't seem to apply > either. > > After digging into the issue, I discovered that JSPWiki wasn't even > checking the policies defined within the jspwiki.policy file. > Com > .ecyrd.jspwiki.auth.AuthorizationManager.checkStaticPermission(WikiSe > ssion,Permission) checks the JVM-wide security policy first, and only > checks the local policy if the JVM-wide policy denies the action. > Since > I don't have Java Security enabled on the JVM, the JVM-wide policy > will > not deny ANY actions. > > So, all that leads me to my question. Don't take this as a dig or > challenge. I've learned in my life that while I can't think of > reasons, > there are plenty out there. Just trying to understand the reasoning. > This is especially true for me currently, as I'm still learning the > JSPWiki codebase and don't have a great deal of background with java > policies! Sooo.... > > Question: Why does the JVM-wide policy apply at this point? If > JSPWiki > is loading its own jspwiki.policy file, should we be deferring to the > JVM-wide policy at all? That policy should be governing what my > application can do to the system/etc, not what my users can do within > the application. Will anything obvious break if I 'eliminate' the JVM > policy check from AuthorizationManager? > > On a side note... I've tried enabling Java Security and was able to > verify that the policies were being processed as expected. With that > said, it's caused me some other pain that I'm still working through > (mainly around the SSO component). I'm not looking for a quick fix > here. I'm just curious as to why JVM-wide is even taken into > account if > JSPWiki is loading a local policy separate. > > I appreciate your time, as well as any responses! Thank you and > have a > good holiday! > > Joseph Hobbs > Email : [EMAIL PROTECTED] > > This e-mail transmission contains information that is confidential > and may be privileged. It is intended only for the addressee(s) > named above. If you receive this e-mail in error, please do not > read, copy or disseminate it in any manner. If you are not the > intended recipient, any disclosure, copying, distribution or use of > the contents of this information is prohibited. Please reply to the > message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer > system. Your assistance in correcting this error is appreciated. > This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.
