You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2010/11/10 22:15:36 UTC
Re: [OT] SecurityManager and Java Policy Files
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] SecurityManager and Java Policy Files
Posted by Mark Thomas <ma...@apache.org>.
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<Connection>() {
> public Connection run()
> {
> DataSource ds = // get from JNDI
> return ds.getConnection();
> }
> });
> }
>
> public List<Person> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] SecurityManager and Java Policy Files
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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<Connection>() {
public Connection run()
{
DataSource ds = // get from JNDI
return ds.getConnection();
}
});
}
public List<Person> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] SecurityManager and Java Policy Files
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] SecurityManager and Java Policy Files
Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org