Re: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Craig R. McClanahan]

Sorry not to get this out earlier ... comments intermixed.

Glenn Nielsen wrote:

 Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
 Work on implementing this proposal is in progress.  Comments please?

 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.


Will it be optional when Tomcat 4 is run by itself (either standalone or behind
a
web server) as well?


 Setting policies for internal Tomcat classes
 

 Security policies will be set using the tomcat.policy file. Security
 checks will be based only on the codeSource of the class matching the
 codeBase for JVM and Tomcat internal classes.

 Example tomcat.policy entries affecting Tomcat internals

 // javac
 grant codeBase "file:${java.home}/lib/-" {
 permission java.security.AllPermission;
 };

 grant codeBase "file:${java.home}/jre/lib/-" {
 permission java.security.AllPermission;
 };

 grant codeBase="file:${tomcat.home}/server/-" {
 permission java.security.AllPermission;
 };

 grant codeBase="file:${tomcat.home}/bin/-" {
 permission java.security.AllPermission;
 };


Note - to be technically correct, references to "tomcat.home" in the entries
above
should be "catalina.home" for Tomcat 4, to be consistent with the system
property
definition that is actually used.


 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";
 };


Is this set of default permissions going to be easily configurable?  I can
imagine
that this would be a popular choice for people who don't want to spend a lot of
time thinking about security.  For example, you might want to grant all webapps
the
ability to connect to the network host and port required by your database
because
you use it in every app.


 // Additional Permissions for tomcat examples context
 grant codeBase="file:${tomcat.home}/webapps/examples/- {
 permission java.util.PropertyPermission "*", "read";
 };

Should the code base actually be restricted to ".../examples/WEB-INF/classes/-"
and
".../examples/WEB-INF/lib/-"?  It means setting up two policy entries instead of
one if a particular app uses both JAR'd and unJAR'd classes, but I suspect that
is
somewhat unusual.


 Security restrictions for using classes
 ---

 StandardClassLoader will implement the SecurityManager.checkPackageAccess()
 method to determine whether the ClassLoader has permission to access the
 packages "sun.,org.apache.catalina.,org.apache.jasper.".

Is org.apache.jasper really special?  It is loaded by the "Shared" classloader
(in
the Tomcat 4 classloader hierarchy) anyway, so it is already going to be
restricted.

And, a web app will need to be able to access these packages to utilize the JSP
servlet, and therefore execute JSP pages.


 If a Context doesn't have the RuntimePermission "*" or
 "accessClassInPackage.{package name}", it will not be allowed to use a
 Class in the package.


 Security restrictions for defining classes
 --

 StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
 method to determine whether the ClassLoader has permission to define a class
 in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".

Same question re: specialness of Jasper, although I can see a stronger case for
prohibiting class *creation* in this package than class *access*.


 If a Context doesn't have the RuntimePermission "*" or
 "defineClassInPackage.{package name}", it will not be allowed to define
 a Class in the package.


 Changing security policies at runtime
 -

 Anytime a Context is reloaded the security policies will be refreshed
 from the tomcat policy file.


 StandardClassLoader
 ---

 All of the code for implementing system, restricted, and allowed
 checks will be removed.  This will be handled by the SecurityManager.


+1

It's only there as a placeholder until security manager support is available.


 Remove the ability to configure a contexts classloader in the
 server.xml 

Re: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Anil Vijendran]

Hi Glenn,

I had a few questions/comments on:


 Jasper JSP class loading

 The work directory will be moved inside the web application context
 /WEB-INF/ directory.  This will make security configuration easier
 and security checks more efficient.  The jasper work dir for a context
 would be /WEB-INF/work/.  This should be safe, other important files
 which need to be protected from outside view are stored in
 WEB-INF such as java properties files and class files.
 /WEB-INF/work will not be added to the contexts class path.

Instead of this, how about having a parallel tree under a user-specified temp dir
with a workdir per web application?

This wouldn't work too well for webapps that are run from the WAR file itself.
(The WAR file could be expanded but that's an implementation detail and not
necessarily true.)

Also, I'm a bit wary about touching any part of the webapp that the user created.
What if I create a jar from the directory for that web application after you
created the tmp files?

As far as I can remember, the work directory needs to be added to the context's
classpath. Am I missing something?

 Jasper will be modified so that each individual jsp page
 will have its own URLClassLoader.  When each jsp page has
 its own URLClassLoader we can remove the need to munge and version
 the jsp java and class file names.  We can also create directory
 paths in the work dir for the context that matches the jsp page
 path in the context.  This will make it easier to view the
 generated source for a jsp page. When a jsp page is recompiled,
 a new instance of the URLClassLoader for that page will be
 created.

At this point I don't have enough details to -1 this. But I'd suggest you consider
this before going ahead. Classloaders are heavyweight objects. JSP pages are
essentially like HTML pages. There can be many many of them. Do you want to have a
heavyweight classloader per JSP page (and one for every update of that page?)


--
Peace, Anil +:-)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[PROPOSAL] Tomcat 4 SecurityManager implementation

[Glenn Nielsen]

Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
Work on implementing this proposal is in progress.  Comments please?


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.


Setting policies for internal Tomcat classes


Security policies will be set using the tomcat.policy file. Security
checks will be based only on the codeSource of the class matching the
codeBase for JVM and Tomcat internal classes.

Example tomcat.policy entries affecting Tomcat internals

// javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};

grant codeBase "file:${java.home}/jre/lib/-" {
permission java.security.AllPermission;
};

grant codeBase="file:${tomcat.home}/server/-" {
permission java.security.AllPermission;
};

grant codeBase="file:${tomcat.home}/bin/-" {
permission java.security.AllPermission;
};


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";
};


Security restrictions for using classes
---

StandardClassLoader will implement the SecurityManager.checkPackageAccess()
method to determine whether the ClassLoader has permission to access the
packages "sun.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"accessClassInPackage.{package name}", it will not be allowed to use a
Class in the package. 
  
 
Security restrictions for defining classes
--
  
StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
method to determine whether the ClassLoader has permission to define a class   
in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".   
If a Context doesn't have the RuntimePermission "*" or  
"defineClassInPackage.{package name}", it will not be allowed to define 
a Class in the package.
   
   
Changing security policies at runtime
-
 
Anytime a Context is reloaded the security policies will be refreshed
from the tomcat policy file. 
 

StandardClassLoader
---
   
All of the code for implementing system, restricted, and allowed
checks will be removed.  This will be handled by the SecurityManager.
 
Remove the ability to configure a contexts classloader in the
server.xml Context element.


ApplicationSecurityManager
--
  
This Class is a replacement for the default SecurityManager and extends
class SecurityManager. 
   
It does a normal permission check first, if that fails it takes additional
steps if the current thread is for a web application context. 
  
When a Context is started or stopped it will need to register with
the ApplicationSecurityManager using methods setContext() and 
removeContext().  
 
Context threads will be named threads with the name set to the
string representing the file URL of the Context.  i.e.
"file:/usr/local/tomcat/webapps/examples".   

Re: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Hans Bergsten]

Glenn Nielsen wrote:
 
 Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
 Work on implementing this proposal is in progress.  Comments please?
 
 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.
 [...]

-0. Why not make it optional for standard use as well? If I use Tomcat
for development only, I'm not concerned with security and don't
want to mess with policy files.

 [...]
 Jasper JSP class loading
 
 
 Jasper will have the old 1.1 compatability code stripped out.

+1

 The work directory will be moved inside the web application context
 /WEB-INF/ directory.  [...]

-1. It should be possible to configure Tomcat so that the work
directory is located under /tmp, or any other standard OS location
for temporary files. Besides, creating files under /WEB-INF will
not work if we one day support running applications straight from
the WAR file.

 Jasper will be modified so that each individual jsp page
 will have its own URLClassLoader.  When each jsp page has
 its own URLClassLoader we can remove the need to munge and version
 the jsp java and class file names.  We can also create directory
 paths in the work dir for the context that matches the jsp page
 path in the context.  This will make it easier to view the
 generated source for a jsp page. When a jsp page is recompiled,
 a new instance of the URLClassLoader for that page will be
 created. [...]

+1. Great!

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Paulo Gaspar]

Tomcat would be a great tool to provide catalogs and presentations on
CD - with additional advantages if there are already web versions of 
such applications. I know of a lot of people (me included) that would
like to use Tomcat this way.

I already implemented a proof of concept where a Delphi application 
is used to configure and start a Java application using JNI and a JVM
on the CD (not installed in the PC). It works very well in Windows.

After this, using a small Delphi GUI to start Tomcat and run the 
installed Web Browser over a Tomcat's site is quite trivial. But we 
must be able to place work files on the temporary file directory or 
we can't use JSPs.


I am not talking about a weird idea, it is something I am working on
and with commercial interest. I even researched, found and tested 
(with very positive results) a java database (HypersonicSQL) to do 
the catalog thing.


Have fun,
Paulo Gaspar

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans
 Bergsten
 Sent: Sunday, January 14, 2001 22:05
  The work directory will be moved inside the web application context
  /WEB-INF/ directory.  [...]
 
 -1. It should be possible to configure Tomcat so that the work
 directory is located under /tmp, or any other standard OS location
 for temporary files. Besides, creating files under /WEB-INF will
 not work if we one day support running applications straight from
 the WAR file.
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Peter Donald]

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 );

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 ;)


/*
 * Copyright (C) The Apache Software Foundation. All rights reserved.
 *
 * This software is published under the terms of the Apache Software License
 * version 1.1, a copy of which has been included with this distribution in
 * the LICENSE file.
 */
package org.apache.avalon.engine;

import java.io.File;
import java.net.URL;
import java.net.MalformedURLException;
import java.security.AccessController;
import java.security.CodeSource;
import java.security.Permission;
import java.security.PermissionCollection;
import java.security.Permissions;
import java.security.Policy;
import java.security.PrivilegedExceptionAction;
import java.security.PrivilegedActionException;
import java.security.cert.Certificate;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.PropertyPermission;
import org.apache.avalon.util.io.FileUtil;
import org.apache.avalon.Component;
import org.apache.avalon.Loggable;
import org.apache.log.Logger;

/**
 * Abstract policy extended in avalon.
 *
 * @author a href="mailto:[EMAIL PROTECTED]"Peter Donald/a
 */
public abstract class AbstractPolicy
extends Policy
implements Component, Loggable
{
protected final static boolean DEBUG = true;

protected final ArrayListm_entries = new ArrayList();

protected Logger m_logger;

/**
 * Internal Policy Entry holder class.
 */
protected final static class PolicyEntry
{
CodeSource  m_codeSource;
Permissions m_permissions;
}

public void setLogger( final Logger logger )
{
m_logger = logger;
}

/**
 * Overide so we can have a per-application security policy 

Re: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Remy Maucherat]

 -0. Why not make it optional for standard use as well? If I use Tomcat
 for development only, I'm not concerned with security and don't
 want to mess with policy files.

Same here. There's a switch for the naming features, and I think it should
be the same with the security manager.

Remy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] Tomcat 4 SecurityManager implementation

[Glenn Nielsen]

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]