Has anyone had experience using Sword4J to determine permissions? http://www.alphaworks.ibm.com/tech/sword4j
>From the site: "The Authorization Analysis functionality determines which authorizations are needed in order to run Java code when a SecurityManager is enabled. The Privilege Code Analysis functionality identifies which portions of code could be made privileged." On Tue, Nov 25, 2008 at 12:47 PM, John Wilander <[EMAIL PROTECTED]> wrote: > Hi all! > > I agree with Gunnar on this one. > > 2008-11-25 18.00, Gunnar Peterson wrote: > >> maybe the problem with least privilege is that it requires that >> developers: >> >> 1. define the entire universe of subjects and objects >> 2. define all possible access rights >> 3. define all possible relationships >> 4. apply all settings >> 5. figure out how to keep 1-4 in synch all the time >> >> do all of this before you start writing code and oh and there are >> basically no tools that smooth the adoption of the above. >> >> i don't think us software security people are helping anybody out in >> 2008 by doing ritual incantations of a paper from the mid 70s that may >> or may not apply to modern computing and anyhow is riddled with ideas >> that have never been implemented in any large scale systems > > To the best of my knowledge the security policy framework for Java is more > or less unused. Why? Because it's designed for static, once-in-a-lifetime > releases of software. > > Writing the policy manually is infeasible so you need to ... > > 1. Instrument the code to output what permissions it needs. Typically with a > custom SecurityManager that logs all checkPermission() calls. See the paper > reference at the end of this email for more info. > > 2. Drive the application with your testbed to actually get the policy > output. Your test cases won't cover all application code so you'll surely > miss policy statements. Threading will be a headache here - you need to > propagate the security context to all running threads so they all output > their needed permissions. > > 3. Then you need to filter out what policy statements actually come from > your application and not from your application server. That's quite easy > based on the package names. > > 4. The next step is to collapse the resulting gigantic policy to something > readable, e.g. merging individual file permissions to cover whole folders. A > lot of parsing and ad hoc rules applied here. You have to write the > collapsing code yourself. Not too nice. > > 5. Now you need to _review_ the generated policy so that it's compliant with > the desired permissions of the application. Any suspicious policy statements > will need to be investigated. This is a good driver for code review but > that's another question. Code changes because of unwanted permissions means > starting all over. > > 6. Then you merge it with the policy file for the application server. There > is one, huh? > > 7. You dig into the application server documentation to sort out policy > deployment. > > 9. System and acceptance testing. You might notice that the server's own > policy doesn't work (server refuses to start). Why? It hasn't been > maintained since nobody uses it. Good luck on updating that one. Here the > missed policy statements from 2 hopefully will be found as security > exceptions. Update testbed and re-iterate the whole process. > > 10. Time to ship. Off you go! > > 11. Darn! We need to patch a few things and release version 1.3.1. Guys, we > need to start all over again with the policy. Anyone up for it? > > > If I'm totally wrong please tell me what to do. I'd really like to deploy > maintainable security policies. Mark Petrovic has written some good things > on this issue > (http://www.onjava.com/pub/a/onjava/2007/01/03/discovering-java-security-req > uirements.html). > > Regards, John Wilander > > -- > John Wilander, Security Architect > www.omegapoint.se > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > _______________________________________________ > -- Rohit Sethi Security Compass http://www.securitycompass.com _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
