tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durfee, Bernard" <Bernard.Dur...@suny.edu>
Subject RE: Pluggable mechanism for loading context config files
Date Thu, 06 Jan 2005 22:46:00 GMT
Mark,
 I disagree, I have always felt it would be a good idea to have the
database passwords and such encrypted when in the context files. Those
context files fly all around stuffed in WAR files and stored in CVS
repositories and 'Hey Bob, does this context file look right?'. That's
an awful lot of chances for someone to 'see' a plain-text password,
whether by malicious activity or a simple 'over the shoulder' accidental
glance.

 If the password was encrypted using a method where the encrypted string
can only be decrypted by Tomcat using a key stored safely on the Tomcat
server. A key which can sit on the server and does not ever need to
leave the server. The key can be used to encrypt passwords, which can
then be put in the context files. Now the risk of someone 'seeing' the
password in the context file is not as damaging, because the encrypted
password won't be useful. In fact this could be used to encrypt the
password, username, SID, etc. so that these details would be obscured as
the context files go from the developer's workstation to home to their
laptop to the test environment, etc.

This is at best a strategy of obfuscation, but I think it is a worthy
feature.

Bernard Durfee

-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org] 
Sent: Thursday, January 06, 2005 5:25 PM
To: Tomcat Developers List
Subject: Re: Pluggable mechanism for loading context config files


Alex,

I would vote '-1' for any such addition Tomcat.

Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database. 
First of all, consider the security risks if the information is stored 
in an unencrypted file somewhere on the server. Assuming that this file 
is not publicaly available, only users with access to the machine can 
access the file. With a little more configuration and possibly some 
network security only users with physical access to the machine can 
access the file and read the password.

If one or more 'untrusted' users has physical access to the machine it 
is pretty much game over from a security point of view. With physical 
access there are a whole host of potential attacks I can think of that 
would enable an attacker to gain access to the file.

Therefore, all we are trying to do is protect the contents of a file 
from a group of users all of whom are authorised to see it. What is the 
point?

Looking at it from another perspective, lets say we do encrypt the file.

How does Tomcat decrypt it? Tomcat needs access to the decryption key. 
If this is in a file, the file needs to be protected. How do you do 
this? This is the same problem we had before. We have just added another

layer. It is a chicken and egg situation with no solution. The same 
applies to providing the password via some 'service'. How does the 
Tomcat process authenticate to this service to retrieve the password? It

needs some credentials. Where are these stored? In a file... and so we 
start all over again...

One thing that could work is not placing the password in a file at all 
but requiring it to be entered at start up. However, this exchanges a 
confidentiality security problem for an availability one - if the system

fails it can only be restarted when there is someone present who knows 
the password. Also, people being people, there is a strong chance this 
password will get written down and your security has just got worse 
rather than better.

Ultimately, the best thing you can do is leave the password unencrypted 
in a file and make sure the machine is electronically and physically 
secured with the right policies and procedures to ensure that it remains

secure.

Regards,

Mark

Roytman, Alex wrote:
> Dear Tomcat developers,
> 
> I would like to implement context config file encryption. It is a 
> pretty useful feature since passwords to various resources are stored 
> in those files Unfortunately the way how context config files are read

> is hard coded (InputSource for Digester is created from 
> FileInputStream) and does not let me do so.
> 
> It would be great if tomcat 5.5 provided some pluggable 
> ConfigFileLoader in HostConfig (and may be on Engine level as well) to

> return InputStream for a given config file name (or decorator for 
> FileInputStream ). It would be also great if it were possible to 
> register context config file extensions other then *.xml - it would 
> allow to use *.exml for encrypted XML config files (will save us a 
> test of the file to se if it is encrypted or plain text)
> 
> If it is not possible to make this enhancement may be you could 
> re-factor ContextConfig class so it can be effectively subclassed and 
> its input stream logic altered
> 
> All you would need to do is to factor out
> 
>     protected void processContextConfig(InputStream) {
>     
>     }
> 
> 
> from
> 
>     protected void processContextConfig(File file) {
>         
>         if (log.isDebugEnabled())
>             log.debug("Processing context [" + context.getName() + "] 
> configuration file " + file);
>         
>         // Add as watched resource so that cascade reload occurs if a
default
>         // config file is modified/added/removed
>         context.addWatchedResource(file.getAbsolutePath());
> 
>         InputSource source = null;
>         InputStream stream = null;
>         try {
>             if (file.exists()) {
>                 stream = new FileInputStream(file);
>                 source =
>                     new InputSource("file://" +
file.getAbsolutePath());
>             } else if (log.isDebugEnabled()) {
>                 log.debug("Context [" + context.getName() + "]
configuration file " + file + " not found");
>             }
>         } catch (Exception e) {
>             log.error(sm.getString("contextConfig.defaultMissing") +
file);
>         }
>         if (source == null)
>             return;
>         if (contextDigester == null){
>             contextDigester = createContextDigester();
>         }
>         synchronized (contextDigester) {
>             try {
>                 source.setByteStream(stream);
> 
> .....
> 
> If processContextConfig(InputStream) is available, we can override 
> this method, read from encrypted stream, decrypt create decrypted 
> stream in memory and pass it to the original (superclass)  
> processContextConfig(InputStream)
> 
> 
> Thank you very much for your assistance
> 
> Alex Roytman
> roytmana@peacetech.com
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> 


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


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


Mime
View raw message