Re: [OT] SecurityManager and Java Policy Files

2010-11-10 Thread Mark Thomas 
On 10/11/2010 21:42, Christopher Schultz wrote:
> To be explicit, if I want a class (say, DbStuff) to be able to make a
> database connection yet prevent other classes from doing so, I need to
> do something like this:
> 
> public class DbStuff
> {
>   protected Connection getConnection()
>   {
> Connection conn = null;
> 
> AccessController.doPrivileged(new PrivilegedAction() {
> public Connection run()
> {
>   DataSource ds = // get from JNDI
>   return ds.getConnection();
> }
>   });
>   }
> 
>   public List getPeople()
>   {
> Connection conn = null;
> 
> try {
>   conn = getConnection();
> 
>   // SELECT * FROM people
> 
>   return people;
> }
>   }
> }
> 
> public class MyTest
> {
>   public static void main(String[] args)
>   {
> new DbStuff().getPeople();
>   }
> }
> 
> So, if I give access to "connect", etc. in my policy file to the DbStuff
> class, then DbStuff can use it's own getConnection method to obtain
> database connections, but MyTest would be unable to, say, use
> DriverManager to create a new connection to the database. Do I have that
> right?

You do, but...

The way DbStuff is written I could extend it and call the protected
getConnection() method directly. You should probably make that method
private.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] SecurityManager and Java Policy Files

2010-11-10 Thread Rainer Jung 

For debugging purposes, this

http://blogs.sun.com/xuelei/entry/fine_granularity_diagnosis_on_security

might be useful. And once you succeeded there's always room for 
improvement, e.g.


http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html ;)

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] SecurityManager and Java Policy Files

2010-11-10 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 11/10/2010 4:29 PM, Mark Thomas wrote:
> On 10/11/2010 21:15, Christopher Schultz wrote:
>> Any help would be greatly appreciated.
> 
> I don't recall ever finding anything that useful. What I can do is
> condense my limited knowledge into a few lines that may help.

Thanks for confirming that I've found thus far: good references are
difficult to find.

> For code to perform some actions (e.g. reading a file, exiting the JVM
> etc) it needs the associated permission when running under a security
> manager.
> 
> The policy file handles mapping code to permissions.

Check.

> When code tries to perform a protected function then:
> - if no privileged block is present in the call stack then every class
> in the call stack must have the necessary permission

This is something that I've only recently realized. When I initially
tried to use a SecurityManaget, I found that I basically had to poke
holes in the policy for /everything/. What I wanted to do was restrict
certain code to, for instance, write to my log file(s) or to make a
connection to the database. Without a privileged block, I had to allow
just about all the code to make network connections because nearly any
code could call into a database routine which (of course), may create a
database connection on demand.

The privileged blocks appear to allow me to restrict the code that can
do that to a very specific set of classes -- ones that explicitly
attempt a privileged action using AccessController.

> - if a privileged block is present in the call stack then every class in
> the call stack from the class performing the action to the privileged
> block must have the necessary permission

Gotcha.

> To take a specific example, consider the PersistentManager. It needs to
> read/write sessions from the file system, create objects, manipulate
> class loaders and a bunch of other stuff that requires permissions.
> Session loading/unloading can be triggered by a web application so it is
> possible for web app code to be in the call stack for a call to load().

A good parallel to my JDBC connection example from above: any part of my
webapp can try to use my database services, yet those "outside" classes
shouldn't be able to directly make a database connection.

> Web apps have minimal permissions that do not include the permissions
> needed by the load() method. The PersistentManager class does have the
> necessary permissions.
> 
> The load() method uses a privileged block so web apps can call the
> load() method without having the necessary permissions. To be secure the
> load() method has to make sure web apps can't trick it into doing
> something it shouldn't.
> 
> Does that help?

Yes, very much.

To be explicit, if I want a class (say, DbStuff) to be able to make a
database connection yet prevent other classes from doing so, I need to
do something like this:

public class DbStuff
{
  protected Connection getConnection()
  {
Connection conn = null;

AccessController.doPrivileged(new PrivilegedAction() {
public Connection run()
{
  DataSource ds = // get from JNDI
  return ds.getConnection();
}
  });
  }

  public List getPeople()
  {
Connection conn = null;

try {
  conn = getConnection();

  // SELECT * FROM people

  return people;
}
  }
}

public class MyTest
{
  public static void main(String[] args)
  {
new DbStuff().getPeople();
  }
}

So, if I give access to "connect", etc. in my policy file to the DbStuff
class, then DbStuff can use it's own getConnection method to obtain
database connections, but MyTest would be unable to, say, use
DriverManager to create a new connection to the database. Do I have that
right?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzbEccACgkQ9CaO5/Lv0PDWjACfeLTFxPEbfW0uTrMEy8Iq5hQG
7i8An0wOcfuRTC9jAdOe0ZzL8UZHiAR9
=H6e3
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] SecurityManager and Java Policy Files

2010-11-10 Thread Mark Thomas 
On 10/11/2010 21:15, Christopher Schultz wrote:
> I'm looking for references that explain the interaction between the
> SecurityManager itself, the policy, signed code, and the use of
> AccessController/PrivilegedAction.
> 
> Online resources and articles as well as dead trees would be fine. My
> Google-fu just isn't turning up anything relevant. I get either horribly
> technical specifications of things or trifles that just say "run under a
> SecurityManager and everything will be secure!".
> 
> Any help would be greatly appreciated.

I don't recall ever finding anything that useful. What I can do is
condense my limited knowledge into a few lines that may help.

For code to perform some actions (e.g. reading a file, exiting the JVM
etc) it needs the associated permission when running under a security
manager.

The policy file handles mapping code to permissions.

When code tries to perform a protected function then:
- if no privileged block is present in the call stack then every class
in the call stack must have the necessary permission
- if a privileged block is present in the call stack then every class in
the call stack from the class performing the action to the privileged
block must have the necessary permission


To take a specific example, consider the PersistentManager. It needs to
read/write sessions from the file system, create objects, manipulate
class loaders and a bunch of other stuff that requires permissions.
Session loading/unloading can be triggered by a web application so it is
possible for web app code to be in the call stack for a call to load().

Web apps have minimal permissions that do not include the permissions
needed by the load() method. The PersistentManager class does have the
necessary permissions.

The load() method uses a privileged block so web apps can call the
load() method without having the necessary permissions. To be secure the
load() method has to make sure web apps can't trick it into doing
something it shouldn't.

Does that help?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] SecurityManager and Java Policy Files

2010-11-10 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

I'm resurrecting this thread because I'd like to return my attention to
running my webapp under a SecurityManager.

On 3/25/2010 4:03 PM, Christopher Schultz wrote:
> This is off-topic in that it doesn't really have anything to do
> specifically with Tomcat, but I would be willing to bet that readers
> would be interested in the answer. Besides, the pool of brain cells
> available to this list is rather deep and I'd love an explanation of
> policies.
> 
> I recently tried to set up Tomcat 6.x running under a SecurityManager.
> As I fell down the rabbit hole, I saw that lots of things needed to be
> granted to my code, which all makes sense in general. What I don't quite
> get is the hierarchy of checks that are done.

Can anyone recommend any literature for understanding the Zen of Java's
SecurityManager and, more specifically, how to properly write your
application to operate under one?

I'm looking for references that explain the interaction between the
SecurityManager itself, the policy, signed code, and the use of
AccessController/PrivilegedAction.

Online resources and articles as well as dead trees would be fine. My
Google-fu just isn't turning up anything relevant. I get either horribly
technical specifications of things or trifles that just say "run under a
SecurityManager and everything will be secure!".

Any help would be greatly appreciated.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzbC3gACgkQ9CaO5/Lv0PASFwCeLUDSfK0n+jFbli4sqRRWPGEf
avYAn0oksVC/YT1Gai/w936m2h7sp6eM
=IPIw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] SecurityManager and Java Policy Files

2010-03-30 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Konstantin,

On 3/29/2010 7:56 PM, Konstantin Kolinko wrote:
> 2010/3/25 Christopher Schultz :
> 
> I will try to be brief in my answers below, so please excuse some
> apparent harshness.
> 
>> (...)
>> In the Tomcat SecurityManager docs
>> (http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html),
>> most of the "grants" in the policy file do not have a codeBase.
> 
> Why are you looking there? The policy file cited there is
> "conf/catalina.policy". I would prefer the live copy over the paper.
> (Though the doc should match the file).

It does, but I've found it's better to give list readers something to
click on instead of saying "hey, get the latest Tomcat tarball and look
at the policy file included". I suppose I could have gotten the link
from svnweb, but, well, that takes a while, too.

>> By the way, I /have/ read
>> http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html but
>> some things are still unclear.
> 
> Java 6 docs are below from here:
> http://java.sun.com/javase/6/docs/technotes/guides/security/index.html
> 
> See also the following document there
> http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc.html
> http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-specTOC.fm.html

I'll take a look at all of those. Thanks for the references.

>> it appears that the SecurityManager is enforcing
>> permissions along with the call chain...
> 
> It is documented in those specifications by Sun. It looks the call
> chain up to the nearest AccessController.doPrivileged().

My question was this: is the immediate caller before the
AcessController.doPrivileged() the one checked, or is the /entire call
chain/ checked recursively? The small amount of evidence I've collected
leads me to that conclusion, and I'd like to be sure so that I can write
policy files without completely losing my sanity.

>> Third: doesn't this make performance really suck?
> 
> As with any performance question: test it yourself and for your own
> application/environment. Only that will give you numbers.

Fair enough.

> It may be that impact of those "security checks" is small compared to
> other bottlenecks in one's application. Though, personally, I do not
> like when a computer performs "useless" work.

This is what I was getting at, though in my current position, it pays to
have as many layers of (reasonable) security as possible. We do have
control over all the code, but I'd also like to make sure that a rogue
programmer/library or careless mistake doesn't really foul things up.

>> such as granting AllPermission to things like bootstrap.jar
> 
> That is determined by the task that this protection performs.
> In general, the idea is that what is installed by "administrator" is
> controlled and thus trusted, but the web applications themselves are
> not trusted by default.

This was my real question here: is the codebase-less grant and the
granting of AllPermission just basically laziness on the part of the
policy writer? Or is there a real reason to grant /all/ privileges to
Tomcat.

Here's what's in the policy file (I refer you to the catalina.policy
file that ships with Tomcat 6.0.26 :) regarding the JDBC driver privileges:

// The permission granted to your JDBC driver
// grant codeBase
"jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar!/-" {
//  permission java.net.SocketPermission
"dbhost.mycompany.com:5432", "connect";
// };

That shows the codebase of the driver's JAR being given a
SocketPermission. If my web application tried to create a JDBC
connection directly (that is, by not using Tomcat's connection pool),
would it fail? My experience with the logging framework suggests that it
would fail.

If I need to create a JDBC connection from within my webapp, do I have
to do something like this:

grant codeBase ".../my-jdbc.jar" { permission ... }
grant codeBase ".../my-service.jar" { permission ...}
grant codeBase "webapps/mywebapp/WEB-INF/classes/-" { permission ... }

all with the same "permission" so that this will work? If I want to get
really anal retentive, can I specify exactly which classes are allowed
to make new JDBC connections by setting this SocketPermission for each
one of them? That gives me great flexibility at the cost of a PITA when
writing my policy file... which is why I suspect people just say "screw
it" and do something like this:

grant {
   permission SocketPermission "...", "resolve, connect";
}

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuyceAACgkQ9CaO5/Lv0PAsvACdFJPEZRrT3ghZ+PbSGCJR6CIO
1q0An2nRvylFW++7ZOOvyuJbENRAnh4C
=gPID
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.

Re: [OT] SecurityManager and Java Policy Files

2010-03-29 Thread Konstantin Kolinko 
2010/3/25 Christopher Schultz :

I will try to be brief in my answers below, so please excuse some
apparent harshness.

>(...)
> In the Tomcat SecurityManager docs
> (http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html),
> most of the "grants" in the policy file do not have a codeBase.

Why are you looking there? The policy file cited there is
"conf/catalina.policy". I would prefer the live copy over the paper.
(Though the doc should match the file).

> most of the

What you mean by "most"?  Are you counting "AllPermission" as "one"
versus all those in the "by default" grant block as "many"?


> By the way, I /have/ read
> http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html but
> some things are still unclear.

Java 6 docs are below from here:
http://java.sun.com/javase/6/docs/technotes/guides/security/index.html

See also the following document there
http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc.html
http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-specTOC.fm.html

> it appears that the SecurityManager is enforcing
> permissions along with the call chain...

It is documented in those specifications by Sun. It looks the call
chain up to the nearest AccessController.doPrivileged().

http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc4.html#24646

http://java.sun.com/javase/6/docs/api/java/security/AccessController.html

> Third: doesn't this make performance really suck?

As with any performance question: test it yourself and for your own
application/environment. Only that will give you numbers.

It may be that impact of those "security checks" is small compared to
other bottlenecks in one's application. Though, personally, I do not
like when a computer performs "useless" work.

> such as granting AllPermission to things like bootstrap.jar

That is determined by the task that this protection performs.
In general, the idea is that what is installed by "administrator" is
controlled and thus trusted, but the web applications themselves are
not trusted by default.

Also if the web applications are not trusted, it would make sense to
limit their control over Tomcat settings, by setting deployXML="false"
on a .

By the way,
Mark's presentations from recent ApacheCons are here:
http://people.apache.org/~markt/presentations/



Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] SecurityManager and Java Policy Files

2010-03-29 Thread Terence M. Bandoian 

Hi, Chris-

I don't remember the question exactly but in my experience I've had to 
grant permissions to all relevant jars that are not within a webapp and 
to the webapp.  (Hopefully, this is at least in the right ballpark for 
your question.)


-Terence


Subject:
RE: [OT] SecurityManager and Java Policy Files
From:
"Caldarale, Charles R" 
Date:
Mon, 29 Mar 2010 09:08:39 -0500
To:
Tomcat Users List 

To:
Tomcat Users List 



From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: [OT] SecurityManager and Java Policy Files

Anyone?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] SecurityManager and Java Policy Files

2010-03-29 Thread Caldarale, Charles R 
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: [OT] SecurityManager and Java Policy Files
> 
> I was counting on you, Chuck! ;)

I've kept the message, and would like to research it for my own edification.  
We're about done with a release cycle here, so I'm hoping time will free up 
Real Soon Now.

(Having to replace two tires and straighten two rims due to bloody Minnesota 
potholes isn't helping the time situation.  At least it's not flooding.)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: [OT] SecurityManager and Java Policy Files

2010-03-29 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 3/29/2010 10:08 AM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Subject: Re: [OT] SecurityManager and Java Policy Files
>>
>> Anyone?
> 
> Sorry, no time to chase it down.

I was counting on you, Chuck! ;)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuw7RUACgkQ9CaO5/Lv0PAwIACfWLvi+J42eE8cAra8dEaIoo84
vWQAnAgKCglPWmQ4SAhb5sAJbdMX4dg5
=7G3M
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] SecurityManager and Java Policy Files

2010-03-29 Thread Caldarale, Charles R 
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: [OT] SecurityManager and Java Policy Files
> 
> Anyone?

Sorry, no time to chase it down.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: [OT] SecurityManager and Java Policy Files

2010-03-29 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anyone?

On 3/25/2010 4:03 PM, Christopher Schultz wrote:
> All,
> 
> This is off-topic in that it doesn't really have anything to do
> specifically with Tomcat, but I would be willing to bet that readers
> would be interested in the answer. Besides, the pool of brain cells
> available to this list is rather deep and I'd love an explanation of
> policies.
> 
> I recently tried to set up Tomcat 6.x running under a SecurityManager.
> As I fell down the rabbit hole, I saw that lots of things needed to be
> granted to my code, which all makes sense in general. What I don't quite
> get is the hierarchy of checks that are done.
> 
> In the Tomcat SecurityManager docs
> (http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html),
> most of the "grants" in the policy file do not have a codeBase. Some of
> them do, such as granting AllPermission to things like bootstrap.jar,
> which presumably means that any class in bootstrap.jar can do anything
> it wants.
> 
> By the way, I /have/ read
> http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html but
> some things are still unclear.
> 
> Since I didn't feel like granting permission to, say, write to my
> application log file, to the entire webapp, I chose to grant that
> privilege only to my log4j.jar file and the classes therein:
> 
> grant codeBase "jar:file:@app-dir@/WEB-INF/lib/log4j-1.2.15.jar!/-" {
>permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
>permission java.util.PropertyPermission "log4j.*", "read";
> };
> 
> (Don't worry about all that @app-dir@ junk: it points to the right place
> eventually, and I didn't feel like replacing it with something plausible
> for publication).
> 
> Anyhow, this would seem to work great, except that I also configure
> commons-logging to use the log4j logger, and the commons-logging library
> tries to initialize the log4j logger at some point, which throws
> permission errors. Hmm. So, I tried adding this, too:
> 
> grant codeBase
> "jar:file:@app-dir@/WEB-INF/lib/commons-logging-1.1.1.jar!/-" {
>permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
>permission java.util.PropertyPermission
> "org.apache.commons.logging.*", "read";
>permission java.util.PropertyPermission "log4j.*", "read";
> };
> 
> That seemed to get me further through the process but then my own
> application code was failing because... guess what? My code wasn't
> allowed to call code that /was/ allowed to write to log4j.log. :(
> 
> Okay, fine:
> 
> grant codeBase "file:@app-dir@/WEB-INF/classes/-" {
>permission java.io.FilePermission "@app-log-dir@/log4j.log", "write";
>permission java.util.PropertyPermission
> "org.apache.commons.logging.*", "read";
>permission java.util.PropertyPermission "log4j.*", "read";
> };
> 
> This seemed to make things happy again, as far as the log file was
> concerned. There are other issues for me to deal with, but this example
> is illustrative: it appears that the SecurityManager is enforcing
> permissions along with the call chain, not just with the finest-grained
> code being checked for its permissions.
> 
> First: do I have this right? The JVM makes sure that permissions are in
> place for every class on the call stack when such permissions are
> checked? I suppose that would make sense, because then you could say
> "well, my JDBC driver does the actual connecting to the database, but I
> certainly don't want some rogue code in my webapp to create such a
> connection... only allow Tomcat to create connections on my behalf".
> 
> Second - as a corollary to the first - is this why most examples of
> policy grants simply say "grant { whatever }" to allow all code running
> in the JVM to have that permission? Because the alternative is so
> onerous that nobody wants to do it? Well, I kinda want to do it, so I
> just want to know what the rules are.
> 
> Third: doesn't this make performance really suck?
> 
> Anyone who could shed some light on my understanding would certainly be
> appreciated. I'm happy to read any references posted as well.
> 
> Thanks,
> -chris

- -
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuws9AACgkQ9CaO5/Lv0PAOwQCgj7lfQLwbrtTjWZtnDi3wlgDD
BHgAn27/t9LOKS3e/2oHRXYHOv3NcTvH
=vE96
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org