tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark H. Wood" <>
Subject Re: Using Environment variables instead of Java -D properties for context.xml substitution
Date Tue, 23 Jan 2018 14:04:45 GMT
Well, there are several layers of problems here, with different ways
of addressing them.

Command lines are available using 'ps', so any secrets written on the
command line are visible to anyone able to get a session on that host,
for the duration of the command.  There's no way around this that I
know of.

Process environment variables may also be visible to all and sundry,
so moving secrets from the command line to the environment just makes
slightly more work for the snooper.  Removing them from the shell's
environment after use may not help, because typically the environment
is cloned when a process is forked, so the service process will have
copies that aren't removed.

The people who wrote the Servlet spec. seem to me to have been
thinking that the context for an instance of an app. would be
generated by an installer program or by the container's management
tools.  You could write a simple script to generate a context
declaration which is customized for a specific instance.  Unlike the
command line or the process environment, files (such as a
free-standing context declaration) can be protected by the
filesystem.  This is your best noninteractive bet.

As mentioned by another, the way to limit availability of
machine-readable secrets to the greatest extent is to require an
operator to type them in at startup.  However, you'll need to consider
the consequences of this if your container is automatically started at
system startup -- you may need a way to let an individual context's
startup wait for an operator to appear without hanging the whole
system startup procedure.  (Automatic startup is another common thing
that the spec. authors seem to have believed to be Somebody Else's

For completeness:  in your own code, you'll also wish to ensure that
you obliterate (not just discard) secrets as soon as you have no
further need for them.  That means that, within the JVM, they should
only ever exist in mutable objects (not String, for example).

Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202

View raw message