Re: Using Environment variables instead of Java -D properties for context.xml substitution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/23/18 9:04 AM, Mark H. Wood wrote: > 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. I would argue that environment variables are more secure than system properties (when passed on the command-line) because accessing a process's environment variables usually requires some appropriate level of access, whereas 'ps' is open to everyone, of course. But of course there are even better solutions... > 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. +1 > 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 Problem.) I have a few machines with encrypted filesystems on them and, because I understand that having the fs password in a startup script is tantamount to not having an encrypted filesystem at all, I have to enter the password for the crypto fs every time the machine is restarted. This happens maybe once per quarter (3 mos... more often when kernel patches are coming out several times per day like recently) and it's a giant pain in my neck. Unless it's absolutely required, don't put a human process in where an automated process will d o. > 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). I disagree. There is almost no way to scrub memory in a JVM process. Hell, it's almost impossible to scrub memory even in a native process due to the way that the OS virtualizes memory regions. The OS can write a page to disk without you even knowing about it, and not your secret is on the disk. Yes, there are ways to tell the OS not to swap that memory, but at some point you end up writing more scrubbing code than anything else. Take the JVM example. Let's say that you have a secret that is only required for a short amount of time. You read it in from somewhere and put it into a char[] object. That char[] object is mutable and sure, you can write 0x00 to all of the char values before you discard the object and allow it to be collected by the GC. But before you have the chance to scrub it, the memory manager can relocate the char[] object to another place within the current (or even a different) heap region. Without native code, there is no way to prevent that from happening. The GC can even run during your scrubbing-operation and you end up with a copy of a half-scrubbed secret sitting around in an unpredictable memory location. Let's say you decide it's super-important to scrub that memory and you understand that you have to pin the object in memory to scrub it properly. So you write a native method to pin/scrub/unpin the object. Well, what was the history of that object *before* you tried to pin it? Okay, now we have to go 100% native and pin our char[] object, read the data from wherever, use it for authentication/signing/whatever, then scrub and unpin the object. Oh, and don't forget to tell the OS not to swap-out that page of memory in the meantime. Bullet-proof, right? Sorry, no. In the process of using that secret to authentication/sign/whatever, you may find that the authentication/signing/whatevering library makes a copy of the secret. Say... for easy-access. Is that library scrubbing the memory? Not sure. Let's say that library ei
Re: Using Environment variables instead of Java -D properties for context.xml substitution
Thanks for the feedback. -Al On Tue, Jan 23, 2018 at 11:05 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Algirdas, > > On 1/23/18 6:11 AM, 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. > > Use sane file permissions? > > While you are at it, why not just put the db username and password > into your application's META-INF/context.xml file where they belong? > > > 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(...). > > We *could* do that, but why? > > Is there a reason to think that file permissions are easier to break > than, well, file permissions (think /proc/[pid]/environ)? > > - -chris > > > On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev > > 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: > >> > >> >> 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 > >> > > > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnXV0dHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjcvQ/8Dtu3ftae5LDBrqLD > AZlkomVg2RnuaASPRIeX+wyDsT7+ojjIknJy3l2pw3z9F/7qp98JZR7AsDb8V+ma > ifRuxWEUrfpHmf+Mant+1DlgF56B+o9zMJevD435XwJiH2P2G6OBnopYvq5StDlN > GF0JN+HUtceastqw91P3SRj9DS8q2K36F6b75r5I+JmDXoDHecbtVXxMMwq55u6l > jXY/FzIUAfxmJnsiWZaYZ2+oFdwe4rWxe6vLTKUyAi17w3g7UcXHpXHzq4s7YlKO > zfqkThTnOUi9loRKQSzfOb6kIDMSmM+MHZ/JrXqRrPQ0h1GxOaea4Wnp5rBg4TBI > 1fkCiSLbv6oa+olZsIqZCVESSSO1yeZYRkAolENqMyRX+vlDjzKJehyIF8LlsnvY > TjITzqEYsp9xSC15JU1OACmRdkOr9d/dS+5hoKT96cfu11Y+bt5My2lYvxUzGHCH > crdTs4j8C5TPN4mksasOOEfuEg5aad0nj5x2lb4meZwUGiQYxmn13JV8c7I0skOM > NtJX2kSxOLFFIpHZpPbY+cds2oYkfZOGFAKjcye7SGRGhuGFMfGohzZDbXIcgMVK > DeioYT+gc+r6Y2gSvzRPISdlzEeRi4oPrXM42vsRs2qvOaacManAqqIOhdAHdPsZ > a4mP2K3f7yHoWBxCG3zhxjli56o= > =MG1G > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Using Environment variables instead of Java -D properties for context.xml substitution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Algirdas, On 1/23/18 6:11 AM, 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. Use sane file permissions? While you are at it, why not just put the db username and password into your application's META-INF/context.xml file where they belong? > 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(...). We *could* do that, but why? Is there a reason to think that file permissions are easier to break than, well, file permissions (think /proc/[pid]/environ)? - -chris > On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev > 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: >> >> > 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 >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnXV0dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjcvQ/8Dtu3ftae5LDBrqLD AZlkomVg2RnuaASPRIeX+wyDsT7+ojjIknJy3l2pw3z9F/7qp98JZR7AsDb8V+ma ifRuxWEUrfpHmf+Mant+1DlgF56B+o9zMJevD435XwJiH2P2G6OBnopYvq5StDlN GF0JN+HUtceastqw91P3SRj9DS8q2K36F6b75r5I+JmDXoDHecbtVXxMMwq55u6l jXY/FzIUAfxmJnsiWZaYZ2+oFdwe4rWxe6vLTKUyAi17w3g7UcXHpXHzq4s7YlKO zfqkThTnOUi9loRKQSzfOb6kIDMSmM+MHZ/JrXqRrPQ0h1GxOaea4Wnp5rBg4TBI 1fkCiSLbv6oa+olZsIqZCVESSSO1yeZYRkAolENqMyRX+vlDjzKJehyIF8LlsnvY TjITzqEYsp9xSC15JU1OACmRdkOr9d/dS+5hoKT96cfu11Y+bt5My2lYvxUzGHCH crdTs4j8C5TPN4mksasOOEfuEg5aad0nj5x2lb4meZwUGiQYxmn13JV8c7I0skOM NtJX2kSxOLFFIpHZpPbY+cds2oYkfZOGFAKjcye7SGRGhuGFMfGohzZDbXIcgMVK DeioYT+gc+r6Y2gSvzRPISdlzEeRi4oPrXM42vsRs2qvOaacManAqqIOhdAHdPsZ a4mP2K3f7yHoWBxCG3zhxjli56o= =MG1G -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using Environment variables instead of Java -D properties for context.xml substitution
It does turtle all the way downbut 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) 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) >> 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
Re: Using Environment variables instead of Java -D properties for context.xml substitution
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 Problem.) 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 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Using Environment variables instead of Java -D properties for context.xml substitution
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) 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 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: 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
Re: Using Environment variables instead of Java -D properties for context.xml substitution
2018-01-23 16:14 GMT+03:00 Peter Kreuser : > BTW: > > >> Am 23.01.2018 um 13:56 schrieb Peter Kreuser : >> >> Algirdas, >> >> >> >>> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas : >>> >>> 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... >> >> Where would you put that script with the text? >> Well if you use a secure vault, then that script would have to know the >> password to the full secure vault... >> >> You get a feel for the problem? >> >> Run Tomcat in a dedicated service user, make the conf only readable for him >> and restrict the access to the user’s home/tomcat dirs... >> >> The admins of the server will have access to all the information anyhow. But >> any other users around will not be able to read the conf, even the java opts >> of the process will be invisible. >> >> Just my 2cts. >> >> Peter > > the commandline parameters (-D) are also in the tomcat logs, thus probably in > your backups and archives. > VersionLoggerListener can also be configured to log the environment variables with logEnv="true". It is not the default setting though. > ad nauseum. The FAQ page: https://wiki.apache.org/tomcat/FAQ/Password Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using Environment variables instead of Java -D properties for context.xml substitution
BTW: > Am 23.01.2018 um 13:56 schrieb Peter Kreuser : > > Algirdas, > > > >> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas : >> >> 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... > > Where would you put that script with the text? > Well if you use a secure vault, then that script would have to know the > password to the full secure vault... > > You get a feel for the problem? > > Run Tomcat in a dedicated service user, make the conf only readable for him > and restrict the access to the user’s home/tomcat dirs... > > The admins of the server will have access to all the information anyhow. But > any other users around will not be able to read the conf, even the java opts > of the process will be invisible. > > Just my 2cts. > > Peter the commandline parameters (-D) are also in the tomcat logs, thus probably in your backups and archives. Peter >> 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) >> 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 >>>> 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 [ma
Re: Using Environment variables instead of Java -D properties for context.xml substitution
Algirdas, > Am 23.01.2018 um 13:27 schrieb Algirdas Veitas : > > 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... > Where would you put that script with the text? Well if you use a secure vault, then that script would have to know the password to the full secure vault... You get a feel for the problem? Run Tomcat in a dedicated service user, make the conf only readable for him and restrict the access to the user’s home/tomcat dirs... The admins of the server will have access to all the information anyhow. But any other users around will not be able to read the conf, even the java opts of the process will be invisible. Just my 2cts. Peter > 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) > 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 >>> 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: >>>> >>>> >>>auth="Container" >>>>type="javax.sql.DataSource" >>>>username="${DB_USERNA
Re: Using Environment variables instead of Java -D properties for context.xml substitution
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... 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) 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 >> 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: >>> >>> >> 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 > >
Re: Using Environment variables instead of Java -D properties for context.xml substitution
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 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: 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
Re: Using Environment variables instead of Java -D properties for context.xml substitution
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(...). On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 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: > > 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 >
RE: Using Environment variables instead of Java -D properties for context.xml substitution
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: 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
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: 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