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. _______________________________________________