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 [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
