Hi Chris,
let me describe what I'm trying to do in more details.
Goals:
* Completely automate tomcat deployment, and make sure deployment is
reproducible and testable in different environment (hence we use ansible+git to
manage installation and _configuration for tomcat)
* Do not make stupid thing (like storing passwords or keys in SCM) just because
we want to automate
* Be as secure as possible
(Working) implementation:
I install and configure tomcat with ansible (server.xml is an ansible template,
on every run ansible re-generates the template and compare it to the deployed
version, so it needs to be able to read the deployed server.xml)
Then I generate a random pin file, the keystore and the private keys (and
relates cert requests) with ansible on the target host.
(Thanks to Jan suggestion) I can now instruct tomcat to read the pin from the
pin file. I do not need to store pin/keys in SCM....
I'm running on linux so I can install the following audit rule:
auditctl -w [pin file] -p warx -F auid!=tomcat -F auid!=4294967295
so *at least* I'm sure that access to the pin file made by anybody but the
tomcat user would be logged (so I know when I was compromised and need to rekey
the cert)
This rule doesn't trigger when I am comparing the deployed server.xml with the
expected version or the deployed keystore (as to check the presence of the key
I do not need the key pin).
It only trigger when I generate the initial pin, somebody compromise my box, I
need to renew certs (which are all events I like to be informed about)
Now back to the tomcat relevant suff:
(at least) in my setup I find it valuable to be able to read secrets from files
I can protect with specific audit rules.
Jan suggested me a viable (and easily implemented) way to do it [1], so I'm ok.
Now the question is, given how easy is to implement Jan solution do you think
my use case deserves an RFE (something like adding keyPassFile attribute to the
Connector )?
I do not know tomcat enough to answer, but if you say so I'll post a BUG.
Regards and thanks for your help,
Luca
[1]
- Add -Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=FilePropertySource to
CATALINA_OPTS
- deploy a jar in tomcat lib with the following class:
public class FilePropertySource implements
org.apache.tomcat.util.IntrospectionUtils.PropertySource {
@Override
public String getProperty(String name) {
if (name.startsWith("file://")) {
try {
return readFile(name.substring(7));
} catch (IOException e) {
throw new RuntimeException("Unable to derefercence property " +
name, e);
}
}
return null;
}
String readFile(String fileName) throws IOException {
FileReader br = new FileReader(fileName);
try {
StringBuilder sb = new StringBuilder();
char[] buff = new char[4096];
int read = -1;
while ((read = br.read(buff)) != -1) {
sb.append(buff, 0, read);
}
return sb.toString();
} finally {
br.close();
}
}
}
- in server.xml use it like ${file:///bla/bla/bla}
----- Original Message -----
> From: "Christopher Schultz" <[email protected]>
> To: "Tomcat Users List" <[email protected]>
> Sent: Thursday, April 16, 2015 7:22:21 AM
> Subject: Re: RFE: read keystorePass from file
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Luca,
>
> On 4/15/15 5:40 PM, Luca Menegus wrote:
> > Hi Christopher (and Konstantin),
> >
> > took some time to reply as I wanted to test your suggestions:
> >
> > - "a parameterized server.xml that pulls the password [...]": If I
> > understood your hint correctly it boils down to passing secrets as
> > JVM args (using -D or env vars). I do not think that would satisfy
> > my use case as it implies passing secrets on command line or
> > environment. Not acceptable for us.
>
> Definitely don't use system properties: those will show up in a ps
> listing, and would take the problem from already-solved to totally-broke
> n.
>
> My actual suggestion was to use a tool like ant to do deployment-time
> replacement of a token *in the file* with another value (the
> password). Something like this:
>
> <Connector
> ...
> keystorePass="@keystorePassword@"
> ...
> />
>
> During deployment, you take
> /path/to/staged/webapp/conf/tomcat-server.xml and copy-with-filtering
> into /path/to/actual/tomcat/conf/server.xml. The resulting file has:
>
> <Connector
> ...
> keystorePass="tiger"
> ...
> />
>
> ... or whatever you told Tomcat to do.
>
> > - "external XML entities": I gave it a try to this as it looked
> > really promising; but I couldn't get it working.
> >
> > If I got it right your suggestion was I should load the keystore
> > password from a file by declaring the file as an external entity
> > in server.xml and then reference it in the keystorePass/keyPass
> > *attribute* of the relevant Connector entity: (PLS know that my
> > DTD/XML-fu doesn't seems to be up to the task so I might be
> > missing something obvious) I looks like loading external entities
> > as attribute values it's forbidden by design [1] ([2] to know about
> > the test I made).
>
> Put the whole <Connector> in your external entity. Note that I've
> never bothered trying this, because it just seems like the most work
> you could do to get the same kind of protection.
>
> > *If I'm not wrong* than the only way to do what I'm trying to do is
> > a patch. If you agree than I'll open an RFE BUG.
>
> Let me get you back to your original question. Let me see if I've got
> this right:
>
> Given #1: You have server.xml in revision control.
> Given #2: You don't want to put a super-secret password into revision
> control.
> Conclusion: You must store the super-secret password outside of
> server.xml.
>
> I don't think that's the only conclusion you could have come to. Let
> me suggest some other possible conclusions, and you tell us if/why
> each of them is not acceptable.
>
> Alt conclusion #1: Use a non-super-secret password. Who cares if
> "tiger" is in revision-control?
>
> Alt conclusion #2: Don't put the password in the <Connector> at all.
> It will default to "changeit". Use "changeit" as the keystore's
> passphrase.
>
> Alt conclusion #3: "Given #2" is not relevant because the super-secret
> password doesn't give a reader any access to anything. There is
> therefore no problem to solve.
>
> What do you think?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVL0cNAAoJEBzwKT+lPKRYDEUP/Rb9oSHGT4f/XwAYT08sgWHD
> y4jXWx0umFK3jzlMssmVM+MHzLlyXGJLFeztK/iT3TuS7kGmQYkwRVOVaTLjPYvq
> SfhsS3Zvei6JEJwRi35iMRc6kz+YjGomyiuLGd0fF9zGou1BXLGCEbq0+QsGD8+A
> ZZF//kV+AAmFtEHQRMvCc1DiaNPhDKqbj9OQgoNBM0u4/CVBtbNE+CgNAl4OCUKy
> wi9Lo8fBTZuNEocsasVGcSdMpxsNV0YKrVdd6hR3Uoc8OxPIdTXv/bHcs5vRaBP1
> EJixeIZgQgLh6NYwd/q8WwbOmrBXE3mn/VgLzeQ7imE5RYIYxCe6zJIMM1kNM28Q
> oKgpS9VotyRyvpLMD7a4Wmltj3tzztErlYQfl46K+ob3lkca0tPeu1mrV6GtkZ1C
> /ihKd/8rkke6RYYKV/4mRgfBDU4tOeuvobrebkSC7CoRj1DS1WCawO9Aq+Me8BcO
> m9/FWBKU+yHmjghn2M0lHzVzTKuOWSvJQePIjML4WGuv9xiv+tl16GOnX9RgUWRD
> SDxzlGK5oHT98Q4D/Cl1mHqfVBUGiCCj39FoR6a9D+SA/k/TLbCutUZtHuM6htYg
> 0L3ttSmi4EpmLVBLvdFjEXqrQ5neVyyFc7YqbgZZnn45HqwXtlg0MqZiQyZsshso
> uxnexdws2vN3wF+D4Sxx
> =tC4S
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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]
