Peter Donald wrote:
>
> At 12:46 14/1/01 -0600, Glenn Nielsen wrote:
> > Tomcat 4 Java SecurityManager Proposal
> >
> >
> >Tomcat 4 will require the Java SecurityManager, use of the
> >SecurityManager will be optional when Tomcat is embedded in
> >another application.
>
> Why not always have it optional possibly determined by a system property
> value ? This way you won't have people complainig about slow down if they
> don't care about security ;) It will also be easier to integrate into other
> products.
>
> >Setting policies for web application contexts
> >---------------------------------------------
> >
> >A web application has its security based on either the default grant in
> >tomcat.policy or an entry for the context which uses the Context path
> >file URL as the codeBase. This policy will be in affect for any Class running
> >within the Context thread no matter which ClassLoader loaded the class
> >which triggered a security check. A default permission to read files in
> >the Context path is granted.
> >
> >// Default permissions for a Context, all contexts have these permissions
> >grant {
> > permission java.util.PropertyPermission "file.separator", "read";
> > permission java.util.PropertyPermission "path.separator", "read";
> > permission java.util.PropertyPermission "line.separator", "read";
> >};
> >
> >// Additional Permissions for tomcat examples context
> >grant codeBase="file:${tomcat.home}/webapps/examples/- {
> > permission java.util.PropertyPermission "*", "read";
> >};
>
> I have actually implemented something similar this in Avalon about 7 hours
> ago checking it in. Avalon has notion of .sars (Server Application
> Archives) which are very similar to .wars in idea. I was having some issues
> with JVM wide policy which you advocate above so I started playing around
> with a per-sar policy.
>
> To do this I had to subclass SecureClassLoader (I did this via
> URLClassLoader) and overide it's method
>
> protected PermissionCollection getPermissions( final CodeSource codeSource );
>
Duh! Somehow that method never popped out when I was looking at the URLClassLoader
class. That will make things even easier.
Your per application config below would work for Tomcat, but it would be nice
to see if a standard java policy file per web application could be used instead.
> I overode this to access a per-sar Policy object. If no policy was given it
> would give full access to the system. As I was embedding policy information
> in another file (an XML file) it looked something like
>
> <policy>
>
> <!--
> <keystore name="foo-keystore"
> location="file:${sar.home}${/}conf${/}keystore"
> type="JKS" />
> <grant signed-by="Fred" code-base="file:${sar.home}/blocks/*"
> key-store="foo-keystore">
> <permission class="java.io.FilePermission" target="/tmp/*"
> action="read,write" />
> </grant>
> -->
> <grant code-base="file:${sar.home}${/}blocks${/}*">
> <permission class="java.security.AllPermission" />
> </grant>
>
> <grant code-base="file:${sar.home}${/}lib${/}*">
> <permission class="java.security.AllPermission" />
> </grant>
>
> To do this I implemented AbstractPolicy (for generic facilities) and
> SarPolicy (for configuring it from XML file). I have attached the relevent
> classes just in case you are interested.
>
> >Future enhancements
> >-------------------
> >
> >See if it is possible and secure to let an individual
> >web application set its security policies in its own
> >policy file located in its /WEB-INF/ directory.
>
> This is a great facility - when implementing the equivelent for Avalon I
> found it vital for a usable system ;)
>
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
