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