Securing Tomcat Context Descriptor

[Brett Parsons <br...@hotmail.com>]

Hi All,

There is a requirement on the server that we have Tomcat 5.0.28 deployed 
that no username/password information can be stored in plaintext (in the 
open).  Like many people, we are using JNDI datasources in our web 
application.  The datasource connection information (including the database 
username/password) is stored in the Tomcat Context Descriptor under 
TOMCATDIR/conf/Catalina/localhost/myApp.xml.

Does Tomcat provide a more secure way of storing the connection information 
stored in these context deployment descriptors?  Has anyone else run into 
the same problem and been able to solve it somehow?

Thanks,

Brett



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: Securing Tomcat Context Descriptor

[Mark Thomas <ma...@apache.org>]

A couple of observations:

- If someone can read the context descriptor they pretty much own
Tomcat and probably the server as well. If this person is unauthorised,
you have big problems regardless of whether or not they have read-only 
access to the database.

- If the password is encrypted, where do you store the decryption key?
Tomcat still needs to be able to decrypt the password in order to use
it to access the database. At best, this is security by obscurity
which is not very good security at all.

You could write some custom code that required the password to be 
entered on the command line when Tomcat starts but this still has the 
following issues:

- If Tomcat goes down, you need someone who knows the password to 
restart it. If the group of people that know the password is small, 
you have an availability issue.

- Chances are that everyone who administers Tomcat will know this 
password. Given that these people should be the only ones with access 
at the OS level to the Tomcat configuration files there seems little 
point in going to all this trouble.

In my experience securing the configuration files (Tomcat & JVM) using 
OS file permissions is usually the appropriate course of action to 
take unless your security environment is very unusual.

Mark

Brett Parsons wrote:
> Hi All,
> 
> There is a requirement on the server that we have Tomcat 5.0.28 deployed 
> that no username/password information can be stored in plaintext (in the 
> open).  Like many people, we are using JNDI datasources in our web 
> application.  The datasource connection information (including the 
> database username/password) is stored in the Tomcat Context Descriptor 
> under TOMCATDIR/conf/Catalina/localhost/myApp.xml.
> 
> Does Tomcat provide a more secure way of storing the connection 
> information stored in these context deployment descriptors?  Has anyone 
> else run into the same problem and been able to solve it somehow?
> 
> Thanks,
> 
> Brett
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: Securing Tomcat Context Descriptor

[Peter Rossbach <pr...@objektpark.de>]

I thing you can use the Java Security Manager and OS level file 
permisssion for this
or wrote your own DataSource JNDI Factory.

Peter

Brett Parsons schrieb:

> Hi All,
>
> There is a requirement on the server that we have Tomcat 5.0.28 
> deployed that no username/password information can be stored in 
> plaintext (in the open).  Like many people, we are using JNDI 
> datasources in our web application.  The datasource connection 
> information (including the database username/password) is stored in 
> the Tomcat Context Descriptor under 
> TOMCATDIR/conf/Catalina/localhost/myApp.xml.
>
> Does Tomcat provide a more secure way of storing the connection 
> information stored in these context deployment descriptors?  Has 
> anyone else run into the same problem and been able to solve it somehow?
>
> Thanks,
>
> Brett
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org