It does turtle all the way down....but it would "solve" having sensitive
information on the Tomcat server exposed either in a file or via "ps -ef |
grep java" (and make sure they are not logged by Tomcat in the logs).
Whether using the original sequence of commands shown or "prompting the
operations persons(s)" as Andre suggested, the total amount of time that
the sensitive information would be exposed "in the clear" would be
minimized to seconds before a restart and seconds after Tomcat and it's web
applications have been successfully deployed.
On Tue, Jan 23, 2018 at 8:40 AM, André Warnier (tomcat) <a...@ice-sa.com>
wrote:
> Hi.
>
> Ok, so let's recurse..
>
> On 23.01.2018 13:27, Algirdas Veitas wrote:
>
>> Andre, my apologies for bringing up a topic that has been repeated ad
>> nauseum.
>>
>> We were thinking of a process like the following, which would eliminate
>> "the information has to available somewhere in a file" on the actual
>> server
>> where Tomcat is running.
>>
>> cd $TOMCAT_HOME/bin
>>> set +o history
>>> export DB_USERNAME=xyz
>>> ./startup.sh
>>>
>> ..... once the process has started
>>
>>> unset DB_USERNAME
>>> set -o history
>>>
>>
>> This process does not eliminate the need to store the values of sensitive
>> information. But by supporting environment variables, one could eliminate
>> using catalina.properties or -DDB_USERNAME, which exposes the information
>> on the server. In our case, operations would get the data from a secure
>> vault and then run the above scripts. I suppose we could get the same
>> effect by modifying catalina.properties, starting the server and then
>> clearing catalina.properties, until the next restart...
>>
>>
> When you mention "operations", you are talking about some persons, right ?
> I omitted to mention this solution before, because it means, in the
> practice, that someone has to be available, to restart Tomcat (for example,
> after a system reboot, an update etc..). So this is not really scalable.
> In such a case, the Tomcat startup script could also just prompt the
> "operations" for the userid/password, on the console. No need to add the
> complexity of an encrypted vault.
> Of course, it means that you need a group of people sharing that role,
> because persons go on holidays sometimes. And unless the sensitive
> information is trivial to remember (and thus insecure), it will need to be
> written down somewhere. As would the password for the secure vault.
>
> It is turtles all the way down.
>
>
> Don't want to restart an old thread, so if preferred, we can stop the
>> discussion. Thank you for your time.
>>
>> On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) <a...@ice-sa.com>
>> wrote:
>>
>> Hi.
>>>
>>> On 23.01.2018 12:11, Algirdas Veitas wrote:
>>>
>>> Thanks for the quick reply George!
>>>>
>>>> We could, but the data is still available, in this case a file, versus
>>>> in
>>>> the output of "ps -ef | grep java". We can obviously encrypt the
>>>> sensitive
>>>> information.
>>>>
>>>> One idea, in order to support injecting Environment Variables would be
>>>> to
>>>> support a syntax of
>>>>
>>>> ${env.DB_USER}
>>>>
>>>> where if the subsitution property starts with "env", then the variable
>>>> could be retrieve by System.getEnv(...) otherwise
>>>> System.getProperty(...).
>>>>
>>>>
>>>> and where does the environment variable value come from ?
>>>
>>> Isn't this the forever-recurring same "chicken-and-egg" kind of issue
>>> that
>>> has been repeated ad nauseam over hundreds of posts on dozens of forums
>>> already ?
>>>
>>> Wherever you put any kind of "sensitive" information, in the end it has
>>> to
>>> be available *somewhere* for Tomcat (or any other server) to read. And if
>>> you encrypt it, then the key for decrypting it has to be available
>>> somewhere also.
>>> And the answer to that, is always the same in the end, no matter how many
>>> recursions you go through : the information has to be available somewhere
>>> in a file, readable *only* by the user-id under which the server runs
>>> (and
>>> of course whoever can create such a file).
>>> And if someone not authorized to do so, has access to that file, then you
>>> have bigger problems than just with the server software.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev <gstanc...@serena.com
>>>> >
>>>> wrote:
>>>>
>>>> Can you use catalina.properties? From the docs [1]
>>>>
>>>>>
>>>>> " All system properties are available including those set using the -D
>>>>> syntax, those automatically made available by the JVM and those
>>>>> configured
>>>>> in the $CATALINA_BASE/conf/catalina.properties file."
>>>>>
>>>>> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Algirdas Veitas [mailto:apvei...@gmail.com]
>>>>> Sent: Monday, January 22, 2018 4:02 PM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Using Environment variables instead of Java -D properties for
>>>>> context.xml substitution
>>>>>
>>>>> Hi,
>>>>>
>>>>> We have a context.xml under $TOMCAT_HOME/conf that looks like this:
>>>>>
>>>>> <Resource name="jdbc/theDB"
>>>>> auth="Container"
>>>>> type="javax.sql.DataSource"
>>>>> username="${DB_USERNAME}"
>>>>> password="${DB_PASSWORD}"
>>>>> driverClassName="oracle.jdbc.OracleDriver"
>>>>> validationQuery="select 1 from dual"
>>>>> testOnBorrow="true"
>>>>> url="${DB_URL}"
>>>>> />
>>>>>
>>>>> if we do something like this in setenv.sh, the substitution works great
>>>>>
>>>>> export DB_USERNAME=xyz
>>>>> export DB_PASSWORD=vvv
>>>>>
>>>>> export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
>>>>> export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
>>>>>
>>>>> However, if on a linux box, if someone did a "ps -ef | grep java", they
>>>>> would be able to see the actual values of these parameters.
>>>>>
>>>>> theuser 127734 1 0 Jan19 ? 00:04:39 /opt/java/bin/java
>>>>> -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
>>>>> tomcat/apache-tomcat/conf/logging.properties
>>>>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>>>> -DDB_USERNAME=xyz
>>>>> -DDB_PASSWORD=vvv
>>>>>
>>>>> Which our operations team does not want....
>>>>>
>>>>> Is there any syntax that Tomcat can recognize to substitute true
>>>>> environment variables (i.e. export DB_USERNAME=xyz) as opposed to Java
>>>>> properties injected into the JVM by -D (i.e. export
>>>>> DB_USERNAME=$DB_USERNAME) ? Haven't been able to find any
>>>>> documentation
>>>>> on it, but thought would ask.
>>>>>
>>>>> Thanks in advance,
>>>>> Al
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
