Re: Pluggable mechanism for loading context config files
Roytman, Alex wrote: Rémy, I do not think that adding a Context listener will do me any good. I need to plug in my own ContextConfig. I know I can plug in my own ContextConfig but I would like to extend tomcat's one with minimum of changes or I will be running risk of being incompatible with next version of tomcat. That's why I am asking if existing ContextConfig could be refactored slightly to permit easy extension Well, we're not going to provide any additional hooks. Since you seem to be reading the code, it is odd you didn't see you could configure the config class used (configClass on Host). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pluggable mechanism for loading context config files
Remy, I am aware of this property on Host and I actually use it - works great I am able to supply my own context configurator. What I would like to do is avoid rewriting significant parts of Tomcat's ContextConfig class to implement my encryption/decryption functionality. I would like to only override tiny part of it responsible for reading XML config files. It can be easily achieved with a tiny ContextConfig refactoring. May I send you proposed changes? Thank you very much for your help Alex Roytman, Alex wrote: Rémy, I do not think that adding a Context listener will do me any good. I need to plug in my own ContextConfig. I know I can plug in my own ContextConfig but I would like to extend tomcat's one with minimum of changes or I will be running risk of being incompatible with next version of tomcat. That's why I am asking if existing ContextConfig could be refactored slightly to permit easy extension Well, we're not going to provide any additional hooks. Since you seem to be reading the code, it is odd you didn't see you could configure the config class used (configClass on Host). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pluggable mechanism for loading context config files
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]
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
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
RE: Pluggable mechanism for loading context config files
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:[EMAIL PROTECTED]
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
RE: Pluggable mechanism for loading context config files
Mark, Bernard, I think you make a good point here. I would like to clarify my purpose. I do not need to hide my passwords from people who maintain the servers - in fact they enter passwords into plain text config files which are encrypted on tomcat startup and stay encrypted. I need to make sure that if the server is compromised no password info should be gathered from its config files I would like to add that there could be two levels of security 1. Naïve - key is stored on tomcat server and therefore context file can be decrypted by the hacker. While it is naïve and can be broken (if hacker finds key in one of java classes) it is zero maintenance and can be used by people who accept this level of security 2. Better one - key is stored on removable media (USB disk, Smart Card ) which is required to be present for tomcat to start From management prospective it is a royal pain to encrypt each password so I prefer to encrypt entire file. I have this setup working but there is one weak link - I can not integrate well with tomcat. I am forced to have Host listener which decrypt all files on start, let contexts start and then delete decrypted copies. Not good - there is window of vulnerability, there is small chance encrypted file will get stuck on tomcat crash (although it will be cleaned up on next restart) plus deleted files can be recovered :-( Anyway I am looking for second line of defense here not an absolute solution. If I could only integrate with tomcat tightly I would be happy :-) PS: I am not asking tomcat developers to develop encryption - just open up file loading process. This pluggable config file loading can be useful for other things besides encryption (eg custom XML entity resolver which able to read some bits of XML from shared repositories (e.g. LDAP)for big installs with many similar configurations) Thanks again Alex Date: Thu, 06 Jan 2005 17:46:00 -0500 From: Durfee, Bernard [EMAIL PROTECTED] Subject: Pluggable mechanism for loading context config files Content-type: text/plain; charset=us-ascii 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:[EMAIL PROTECTED] 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
Re: Pluggable mechanism for loading context config files
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)
You should be able to easily plug your own Host or Context listener for
configuration.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pluggable mechanism for loading context config files
Alex, Thanks for the clarification of the requirement. I think I still need some convincing ;). I view the naive level as, at best, security by obscurity. Whilst it might make people feel secure, it doesn't add much, if anything in terms of real security. On first impression the second option is more promising but if the machine is compromised a hacker doesn't need the password, they just need to supply a modified class/jar that exposes the password somehow and then sit back and wait for the machine to reboot. You could prevent this by digitally signing all of the 'approved' Java and using a security manager but then you have to protect the security policy file from compromise and you are back to square one. :) So the second option is really no more than a more complex security by obscurity. Stepping back from this a bit, have you done a full security audit of the system? Is this really the highest security risk you need to mitigate? It is possible that this is the case but I would be surprised. Bernard makes an interesting point about keeping production settings separate from the development environment but my own view is that procedure rather than technology is the way to handle this. Mark Roytman, Alex wrote: Mark, Bernard, I think you make a good point here. I would like to clarify my purpose. I do not need to hide my passwords from people who maintain the servers - in fact they enter passwords into plain text config files which are encrypted on tomcat startup and stay encrypted. I need to make sure that if the server is compromised no password info should be gathered from its config files I would like to add that there could be two levels of security 1. Naïve - key is stored on tomcat server and therefore context file can be decrypted by the hacker. While it is naïve and can be broken (if hacker finds key in one of java classes) it is zero maintenance and can be used by people who accept this level of security 2. Better one - key is stored on removable media (USB disk, Smart Card ) which is required to be present for tomcat to start From management prospective it is a royal pain to encrypt each password so I prefer to encrypt entire file. I have this setup working but there is one weak link - I can not integrate well with tomcat. I am forced to have Host listener which decrypt all files on start, let contexts start and then delete decrypted copies. Not good - there is window of vulnerability, there is small chance encrypted file will get stuck on tomcat crash (although it will be cleaned up on next restart) plus deleted files can be recovered :-( Anyway I am looking for second line of defense here not an absolute solution. If I could only integrate with tomcat tightly I would be happy :-) PS: I am not asking tomcat developers to develop encryption - just open up file loading process. This pluggable config file loading can be useful for other things besides encryption (eg custom XML entity resolver which able to read some bits of XML from shared repositories (e.g. LDAP)for big installs with many similar configurations) Thanks again Alex Date: Thu, 06 Jan 2005 17:46:00 -0500 From: Durfee, Bernard [EMAIL PROTECTED] Subject: Pluggable mechanism for loading context config files Content-type: text/plain; charset=us-ascii 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:[EMAIL PROTECTED] 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
RE: Pluggable mechanism for loading context config files
Rémy, I do not think that adding a Context listener will do me any good. I need to plug in my own ContextConfig. I know I can plug in my own ContextConfig but I would like to extend tomcat's one with minimum of changes or I will be running risk of being incompatible with next version of tomcat. That's why I am asking if existing ContextConfig could be refactored slightly to permit easy extension Thank you for your help Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
