Re: running tomcat6 under a different user than root (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/29/2010 10:04 AM, Mark Thomas wrote: On 29/10/2010 14:53, Ronald Klop wrote: If you have a webapp where users log in you can use there login/password to login on the database. A little bit inconvenient for the DBA but you don't have passwords on your servers. It isn't quite that clear cut. There are some trade-offs to make with this approach (and I'm not sure I like them). 1. The user's password has to be available in plain text. That prevents you from storing digested passwords in the realm. This can be avoided by using a random key created during webapp startup (and persisted across re-deploys, but not undeploy/deploy) to encrypt all the passwords during runtime. That key might still be discoverable using the techniques you've already described (reflection, etc.). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO0MsACgkQ9CaO5/Lv0PAcqACgvWB5P4lsdOlIGwN8t4fY+S93 TgEAn2109aeRK0pGMAarSECByf1IiHS5 =101I -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darryl, On 10/29/2010 9:19 AM, Darryl Lewis wrote: Are you serious? Why do we bother with SSL then? Lets just send everything in clear text... You might be misunderstanding the way that SSL works if you think these two are comparable. A simple database credential system using a username and password is much different than SSL, which uses asymmetric keys to negotiate a symmetric key during the handshake. The symmetric key (analogous to the username/password pair above) is always sent via an encrypted channel and never plaintext. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO0XgACgkQ9CaO5/Lv0PDB9QCgv0qNLPwg50bpK+OWh11Gq5Qh 1AUAn3mP4Rt6YFao3CXsde+62z/rFoZP =lTNZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daryl, On 10/30/2010 5:11 PM, Darryl Lewis wrote: That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? Are you going to tell me that is complete nonsense? The credentialing mechanism is the keyboard and the user's fingers, not a file on the filesystem. What you're suggesting here is that /etc/passwd is the same as conf/server.xml when in reality /etc/passwd is analogous to the password database maintained by the db. According to your 'argument' that is 'security by obscurity'. You better break that to the GNU crowd gently. The GNU crowd did not develop the /etc/passwd standard. Having a username and password in clear text allows another account to be compromised. Yes, it does. Nobody is arguing that. What we're saying is that, given these requirements, security is not possible. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO1H8ACgkQ9CaO5/Lv0PBNGgCeNh8ztnnpdMIh1M6ctUH3hld+ KM0AnAnQ9myujfrFPba8RcmD85OcYvkA =JV6U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 22:11, Darryl Lewis wrote: Yeah, well reasoned rebuttal therenot. Oh, I don't know. It was succinct, to the point, and unlike your statement, accurate. You declared, on a public mailing list which is republished on web based forums and is therefore Googlable, that Tomcat wasn't suitable for use in a secure environment. That statement is false* and demonstrably so, because it _is_ being used in secure environments. Other messages in the thread contain more information, but I'll reiterate a few points here. If the attacker has the same (or higher) level of access to the JVM process as the user under which the process is running, 'encrypting' a DB password is meaningless, unless you are able to pass an hashed password directly to the DB**. Even that doesn't help much, as the attacker may still have the ability to make a connection and extract data from the DB. What's the use of obfuscating the password, if connection is still usable? If the attacker the same access as the server user, what's to stop them from simply adding a malicious jar and restarting the process, or deploying their own hostile application(s)? Or causing a heap dump which contains the state of every object and can easily be examined to find specific values? Or more exotic things like (in Java 6) dynamically adding an agent via the Attach API rewriting classes to include malicious code? You'll note that I haven't specifically referred to Tomcat, because each of these applies to any JVM process. So are you also saying that WebSphere, WebLogic, Geronimo, JBoss, Glassfish et al are unsuitable for running in a secure environment? That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? On my *nix OS, it's not /etc/passwd, it's /etc/shadow which contains the hashes - and it isn't world readable, because allowing anyone/everyone access to your passwords, hashed or not, is bad. Apply the proper file permissions. QED. p * Don't take my word for it: http://www.owasp.org/index.php/Securing_tomcat#Cleartext_Passwords_in_CATALINA_HOME.2Fconf.2Fserver.xml ** I tried finding a way to pass a hashed password to a well-known commercial-DB-vendors flagship product recently at the behest of a client, and wasn't able to. I'd be interested to know how many DBs *can* handle hashed passwords. 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 22:11, Darryl Lewis wrote: That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? Are you going to tell me that is complete nonsense? Yet again you demonstrate your lack of understanding in this area. Those are hashes since the OS never needs access to the password in plain text. The fundamental difference in the database resource password use case is that Tomcat must have access to the password in plain text. Having a username and password in clear text allows another account to be compromised. And, if that account is on another box holding your DB, then the attacker has two boxes for the price of one. This is additionally worse, as in a secure environment, the DB is usually in a different architecture layer or vlan. The username and password the application uses to connection to the database should have the bare minimum permissions necessary for the application to operate correctly. That should not equate to root for the database and certainly shouldn't equate to root on the box. On 31/10/10 8:01 AM, Pid * p...@pidster.com wrote: On 30 Oct 2010, at 15:20, Darryl Lewis darryl.le...@unsw.edu.au wrote: Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. Complete nonsense. +1 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 31/10/2010 04:53, Mladen Turk wrote: On 10/30/2010 07:28 PM, Mark Thomas wrote: On 30/10/2010 12:59, Mladen Turk wrote: On 10/29/2010 03:29 PM, Mark Thomas wrote: I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Agreed. If the hacker is already logged in with the same uid, there isn't much you can do. However that make me wonder why are we keeping the passwords in memory unencrypted. I suppose we should do at least some memory cleansing for any intermediate security related processing product. Unfortunately the database password for a database resource needs to be available throughout the life of the Tomcat process. Well, in theory, once loaded can be kept encrypted inside in-memory key store using a random key and disk based salt. This would require a disk read on each database authz to get the password from in-memory key store however, so might be a performance issue. And still doesn't protect from an attacker that has compromised the Tomcat process and/or the user the process is running as. All we are doing here is constructing more and more elaborate security by obscurity mechanisms. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 31/10/2010 12:29, Mark Thomas wrote: On 31/10/2010 04:53, Mladen Turk wrote: On 10/30/2010 07:28 PM, Mark Thomas wrote: On 30/10/2010 12:59, Mladen Turk wrote: On 10/29/2010 03:29 PM, Mark Thomas wrote: I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Agreed. If the hacker is already logged in with the same uid, there isn't much you can do. However that make me wonder why are we keeping the passwords in memory unencrypted. I suppose we should do at least some memory cleansing for any intermediate security related processing product. Unfortunately the database password for a database resource needs to be available throughout the life of the Tomcat process. Well, in theory, once loaded can be kept encrypted inside in-memory key store using a random key and disk based salt. This would require a disk read on each database authz to get the password from in-memory key store however, so might be a performance issue. And still doesn't protect from an attacker that has compromised the Tomcat process and/or the user the process is running as. All we are doing here is constructing more and more elaborate security by obscurity mechanisms. This would make a good discussion item for Thursday evening's meetup (free to all) at ApacheCon this week. I'll add it to the wiki page. http://wiki.apache.org/tomcat/TomcatAtApacheConNA2010 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: running tomcat6 under a different user than root (debian)
-Original Message- From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Sent: Saturday, October 30, 2010 3:12 PM To: Tomcat Users List Subject: Re: running tomcat6 under a different user than root (debian) Yeah, well reasoned rebuttal therenot. That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? Are you going to tell me that is complete nonsense? This is really much less useful than you would think. I had a Linux machine get hacked once. The (not tomcat, and not written by me) poorly designed webapp ran as root. The attacker used an error in PHP to retrieve /etc/shadow. Once they had that file, they looked up the hashed passwords in a dictionary. They then installed a simple shell running on a port and setup a trojaned SSH daemon. I pretty much noticed right away because the SSH daemon that didn't work right. You can read a complete narrative here: http://archive.lug.boulder.co.us/Week-of-Mon-20070903/035231.html The first time I heard of this attack was in Cliff Stoll's book the Cuckoo's Egg. If you haven't read it, you should. The issues haven't changed in the 20 years since it was published. You should also read Bruce Schneier's book Applied Cryptography. It's really tough to understand computer security without understanding cryptography. According to your 'argument' that is 'security by obscurity'. You better break that to the GNU crowd gently. Having a username and password in clear text allows another account to be compromised. And, if that account is on another box holding your DB, then the attacker has two boxes for the price of one. This is additionally worse, as in a secure environment, the DB is usually in a different architecture layer or vlan. On 31/10/10 8:01 AM, Pid * p...@pidster.com wrote: On 30 Oct 2010, at 15:20, Darryl Lewis darryl.le...@unsw.edu.au wrote: Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. Complete nonsense. George Sexton MH Software, Inc. 303 438-9585 www.mhsoftware.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
http://www.devdoctor.com/blog/2009/07/how-to-encrypt-passwords-in-tomcat.php On 31/10/10 11:44 PM, Mark Thomas ma...@apache.org wrote: On 31/10/2010 12:29, Mark Thomas wrote: On 31/10/2010 04:53, Mladen Turk wrote: On 10/30/2010 07:28 PM, Mark Thomas wrote: On 30/10/2010 12:59, Mladen Turk wrote: On 10/29/2010 03:29 PM, Mark Thomas wrote: I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Agreed. If the hacker is already logged in with the same uid, there isn't much you can do. However that make me wonder why are we keeping the passwords in memory unencrypted. I suppose we should do at least some memory cleansing for any intermediate security related processing product. Unfortunately the database password for a database resource needs to be available throughout the life of the Tomcat process. Well, in theory, once loaded can be kept encrypted inside in-memory key store using a random key and disk based salt. This would require a disk read on each database authz to get the password from in-memory key store however, so might be a performance issue. And still doesn't protect from an attacker that has compromised the Tomcat process and/or the user the process is running as. All we are doing here is constructing more and more elaborate security by obscurity mechanisms. This would make a good discussion item for Thursday evening's meetup (free to all) at ApacheCon this week. I'll add it to the wiki page. http://wiki.apache.org/tomcat/TomcatAtApacheConNA2010 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 31/10/2010 21:44, Darryl Lewis wrote: http://www.devdoctor.com/blog/2009/07/how-to-encrypt-passwords-in-tomcat.php That article is a little confused. Using digest in a Realm won't help you obfuscate a password in a DataSource defined in server.xml (or anywhere else). p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: running tomcat6 under a different user than root (debian)
Am 29.10.2010 15:29, schrieb Mark Thomas: On 29/10/2010 14:19, Darryl Lewis wrote: Are you serious? Completely. If you have a scheme that encrypts the database username and password in server.xml and provides genuine additional security over and above limiting access to server.xml to the user running Tomcat (and root) I'd love to hear it. I'd also be amazed. Just curious: What username/password are you talking about that would be stored in server.xml? There is sth. in tomcat-users.xml. Did you mean that? -- Christoph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 09:19, Christoph Kukulies wrote: Am 29.10.2010 15:29, schrieb Mark Thomas: On 29/10/2010 14:19, Darryl Lewis wrote: Are you serious? Completely. If you have a scheme that encrypts the database username and password in server.xml and provides genuine additional security over and above limiting access to server.xml to the user running Tomcat (and root) I'd love to hear it. I'd also be amazed. Just curious: What username/password are you talking about that would be stored in server.xml? There is sth. in tomcat-users.xml. Did you mean that? DB username/passwords in DataSource definitions, presumably. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: running tomcat6 under a different user than root (debian)
Use encryption http://java.sys-con.com/node/393364 On 30/10/10 8:41 PM, Pid p...@pidster.com wrote: On 30/10/2010 09:19, Christoph Kukulies wrote: Am 29.10.2010 15:29, schrieb Mark Thomas: On 29/10/2010 14:19, Darryl Lewis wrote: Are you serious? Completely. If you have a scheme that encrypts the database username and password in server.xml and provides genuine additional security over and above limiting access to server.xml to the user running Tomcat (and root) I'd love to hear it. I'd also be amazed. Just curious: What username/password are you talking about that would be stored in server.xml? There is sth. in tomcat-users.xml. Did you mean that? DB username/passwords in DataSource definitions, presumably. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 10/29/2010 03:29 PM, Mark Thomas wrote: I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Agreed. If the hacker is already logged in with the same uid, there isn't much you can do. However that make me wonder why are we keeping the passwords in memory unencrypted. I suppose we should do at least some memory cleansing for any intermediate security related processing product. On unixes the memory is uid readable, but windows will basically allow any user to dump any process memory. In that case server.xml can have correct ACL set up, but one will still be able to search for a well known locations in memory. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: running tomcat6 under a different user than root (debian)
From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Subject: Re: running tomcat6 under a different user than root (debian) Use encryption http://java.sys-con.com/node/393364 Sorry, that just moves the problem. The article completely ignores the issue of where to put the decryption key - which must be in plain text somewhere. As Mark pointed out, obfuscation != security. - Chuck P.S. Interesting that the author of that article was using a Tomcat already three years old at the time of publication; doesn't really help the somewhat questionable credibility. (Reference implementations shouldn't be used in production? Where did he get that one?) THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. If cracking an app will let you get passwords on another box, that is weak security. On 30/10/10 11:27 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Subject: Re: running tomcat6 under a different user than root (debian) Use encryption http://java.sys-con.com/node/393364 Sorry, that just moves the problem. The article completely ignores the issue of where to put the decryption key - which must be in plain text somewhere. As Mark pointed out, obfuscation != security. - Chuck P.S. Interesting that the author of that article was using a Tomcat already three years old at the time of publication; doesn't really help the somewhat questionable credibility. (Reference implementations shouldn't be used in production? Where did he get that one?) THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 13:27, Caldarale, Charles R wrote: P.S. Interesting that the author of that article was using a Tomcat already three years old at the time of publication; doesn't really help the somewhat questionable credibility. (Reference implementations shouldn't be used in production? Where did he get that one?) That's fine. Tomcat hasn't been the reference implementation since sometime during Tomcat 4 development (I think - it might have been even earlier). More -ve points for the author's credibility. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 15:19, Darryl Lewis wrote: Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. If cracking an app will let you get passwords on another box, that is weak security. You are missing the point. There is no way to achieve what you are trying to achieve using encryption. Tomcat has to be able to access a plain-text form of the username and password in order to use them to connect to the database. If the Tomcat process can do this then an attacker that has compromised the Tomcat process can do this. You could use a security manager to limit what a compromised application can do. The downside is writing apps that run under a security manager is hard. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 12:59, Mladen Turk wrote: On 10/29/2010 03:29 PM, Mark Thomas wrote: I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Agreed. If the hacker is already logged in with the same uid, there isn't much you can do. However that make me wonder why are we keeping the passwords in memory unencrypted. I suppose we should do at least some memory cleansing for any intermediate security related processing product. Unfortunately the database password for a database resource needs to be available throughout the life of the Tomcat process. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30/10/2010 18:27, Mark Thomas wrote: On 30/10/2010 15:19, Darryl Lewis wrote: Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. If cracking an app will let you get passwords on another box, that is weak security. You are missing the point. There is no way to achieve what you are trying to achieve using encryption. Tomcat has to be able to access a plain-text form of the username and password in order to use them to connect to the database. If the Tomcat process can do this then an attacker that has compromised the Tomcat process can do this. Oh, and if it wasn't obvious this applies to *any* application server. If they claim anything different then all you will be getting is security by obscurity. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 30 Oct 2010, at 15:20, Darryl Lewis darryl.le...@unsw.edu.au wrote: Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. Complete nonsense. p If cracking an app will let you get passwords on another box, that is weak security. On 30/10/10 11:27 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Subject: Re: running tomcat6 under a different user than root (debian) Use encryption http://java.sys-con.com/node/393364 Sorry, that just moves the problem. The article completely ignores the issue of where to put the decryption key - which must be in plain text somewhere. As Mark pointed out, obfuscation != security. - Chuck P.S. Interesting that the author of that article was using a Tomcat already three years old at the time of publication; doesn't really help the somewhat questionable credibility. (Reference implementations shouldn't be used in production? Where did he get that one?) THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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
Re: running tomcat6 under a different user than root (debian)
Yeah, well reasoned rebuttal therenot. That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? Are you going to tell me that is complete nonsense? According to your 'argument' that is 'security by obscurity'. You better break that to the GNU crowd gently. Having a username and password in clear text allows another account to be compromised. And, if that account is on another box holding your DB, then the attacker has two boxes for the price of one. This is additionally worse, as in a secure environment, the DB is usually in a different architecture layer or vlan. On 31/10/10 8:01 AM, Pid * p...@pidster.com wrote: On 30 Oct 2010, at 15:20, Darryl Lewis darryl.le...@unsw.edu.au wrote: Well so far all this discussion has done is to make me realise that tomcat should not be used in an environment that requires security. Complete nonsense. p If cracking an app will let you get passwords on another box, that is weak security. On 30/10/10 11:27 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Subject: Re: running tomcat6 under a different user than root (debian) Use encryption http://java.sys-con.com/node/393364 Sorry, that just moves the problem. The article completely ignores the issue of where to put the decryption key - which must be in plain text somewhere. As Mark pointed out, obfuscation != security. - Chuck P.S. Interesting that the author of that article was using a Tomcat already three years old at the time of publication; doesn't really help the somewhat questionable credibility. (Reference implementations shouldn't be used in production? Where did he get that one?) THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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
RE: running tomcat6 under a different user than root (debian)
From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Subject: Re: running tomcat6 under a different user than root (debian) That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? No, we encrypt them in Linux because the (very outmoded) /etc/passwd file is readable by anyone. Your critical server files should not have 644 on them, and any Java-based app servers you're running should have a security manager enabled if you can't trust your webapps. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 10/30/2010 11:11 PM, Darryl Lewis wrote: Yeah, well reasoned rebuttal therenot. That's why we encrypt passwords in unix, or haven't you looked at etc/passwd lately? Have *you* ever looked at the etc/passwd? First of all it is not encrypted. It contains a hash value of the password so you cannot get the clear text password back. Are you going to tell me that is complete nonsense? Since connection to database requires a real password if encrypted on the disk there must be a way to decrypt it at runtime. This can be done by some obscurity algorithm or by providing a key store password at application startup. Providing a key store password is either done interactively or by a special hardware devices. Since the second are expensive and the first one are inappropriate for server based software, securing the passwords in clear text form is the only solution. Just obscuring the passwords with what ever algorithm is not secure. Having a username and password in clear text allows another account to be compromised. If your database user equals to an user account on other box then yes. But FYI those are usually kept different. Aye you going to tell me that you use login accounts for database accounts? Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 10/30/2010 07:28 PM, Mark Thomas wrote: On 30/10/2010 12:59, Mladen Turk wrote: On 10/29/2010 03:29 PM, Mark Thomas wrote: I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Agreed. If the hacker is already logged in with the same uid, there isn't much you can do. However that make me wonder why are we keeping the passwords in memory unencrypted. I suppose we should do at least some memory cleansing for any intermediate security related processing product. Unfortunately the database password for a database resource needs to be available throughout the life of the Tomcat process. Well, in theory, once loaded can be kept encrypted inside in-memory key store using a random key and disk based salt. This would require a disk read on each database authz to get the password from in-memory key store however, so might be a performance issue. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
running tomcat6 under a different user than root (debian)
How can I run tomcat under a different user than root (debian e.g.)? -- Christoph P.U. Kukulies - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 10:57, Christoph Kukulies wrote: How can I run tomcat under a different user than root (debian e.g.)? Use a service wrapper. http://tomcat.apache.org/tomcat-6.0-doc/setup.html#Unix_daemon p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: running tomcat6 under a different user than root (debian)
2010/10/29 Christoph Kukulies k...@kukulies.org: How can I run tomcat under a different user than root (debian e.g.)? How do you run it now? Nobody should run Tomcat as root. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
No one should, but I had a supplier recommend to run their application as root. All their scripts and configuration instructions were for running as root. Needless to say I didn't run it as that and rewrote their installation scripts. Now I have to try and convince them that storing the database connection username and passwords in plaintext are a bad idea... On 29/10/10 9:42 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2010/10/29 Christoph Kukulies k...@kukulies.org: How can I run tomcat under a different user than root (debian e.g.)? How do you run it now? Nobody should run Tomcat as root. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 12:03, Darryl Lewis wrote: No one should, but I had a supplier recommend to run their application as root. All their scripts and configuration instructions were for running as root. Needless to say I didn't run it as that and rewrote their installation scripts. Now I have to try and convince them that storing the database connection username and passwords in plaintext are a bad idea... What is the alternative? If the config files containing that information are only readable by the user running Tomcat, and that user doesn't have login access - assuming you're using the service wrapper script to start up, then the information is protected, no? p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 12:03, Darryl Lewis wrote: Now I have to try and convince them that storing the database connection username and passwords in plaintext are a bad idea... I trust that the supplier replies that there is nothing wrong with this approach. The most you'll ever be able to achieve is limiting access to the username and password to the user running the Tomcat process. Since the OS provides a fine set of file permissions for doing exactly that, why bother with anything else? 'encrypting' the username and password will never be anything more than security by obscurity and that is no security at all. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
Encrypt the username and passwords using Realm configuration. You should always assume there is the possibility that a user will get access to the system via a badly written program. Whilst they might get some system access, you should make it as difficult as possible for them to jump to the next box. If you give read access on server.xml only to root user, it requires that Tomcat is started with root privileges, which is really bad. If a person gets access, they automatically get root privildges. Then entire idea is to make it difficult for a person to get very far quickly. If you run TC as a non-root user, even if they crack the app to get system access, they still have to go further to get root. On 29/10/10 10:42 PM, Pid p...@pidster.com wrote: On 29/10/2010 12:03, Darryl Lewis wrote: No one should, but I had a supplier recommend to run their application as root. All their scripts and configuration instructions were for running as root. Needless to say I didn't run it as that and rewrote their installation scripts. Now I have to try and convince them that storing the database connection username and passwords in plaintext are a bad idea... What is the alternative? If the config files containing that information are only readable by the user running Tomcat, and that user doesn't have login access - assuming you're using the service wrapper script to start up, then the information is protected, no? p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
Are you serious? Why do we bother with SSL then? Lets just send everything in clear text... On 29/10/10 11:03 PM, Mark Thomas ma...@apache.org wrote: On 29/10/2010 12:03, Darryl Lewis wrote: Now I have to try and convince them that storing the database connection username and passwords in plaintext are a bad idea... I trust that the supplier replies that there is nothing wrong with this approach. The most you'll ever be able to achieve is limiting access to the username and password to the user running the Tomcat process. Since the OS provides a fine set of file permissions for doing exactly that, why bother with anything else? 'encrypting' the username and password will never be anything more than security by obscurity and that is no security at all. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 14:19, Darryl Lewis wrote: Are you serious? Completely. If you have a scheme that encrypts the database username and password in server.xml and provides genuine additional security over and above limiting access to server.xml to the user running Tomcat (and root) I'd love to hear it. I'd also be amazed. Why do we bother with SSL then? Lets just send everything in clear text... Different information in a different environment with different threats. I never said passwords should never be protected. I was quite specific that trying to encrypt usernames and passwords in server.xml (or context.xml for that matter) for database resources is a complete waste of time. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: running tomcat6 under a different user than root (debian)
From: Darryl Lewis [mailto:darryl.le...@unsw.edu.au] Subject: Re: running tomcat6 under a different user than root (debian) Are you serious? Definitely. Think it through. Why do we bother with SSL then? Lets just send everything in clear text... Perhaps you failed to notice that traffic over the wire is available to pretty much anyone, but bits on the server hard drive are not (or at least shouldn't be, if you've taken the most basic security steps). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 14:18, Darryl Lewis wrote: Encrypt the username and passwords using Realm configuration. Realms have nothing to do with the usernames and passwords used to connect to databases defined via Resource tags. You should always assume there is the possibility that a user will get access to the system via a badly written program. Whilst they might get some system access, you should make it as difficult as possible for them to jump to the next box. If Tomcat has access to a database and the attacker has access to a shell prompt (or similar) with the same privileges as Tomcat then the attacker has access to the database and there is absolutely nothing you can do to prevent that. If you give read access on server.xml only to root user, No-one is suggesting that. Go read what Pid wrote again. Tomcat is started with root privileges, which is really bad. Agreed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On Friday 29 October 2010 15:34:29 Mark Thomas wrote: If Tomcat has access to a database and the attacker has access to a shell prompt (or similar) with the same privileges as Tomcat then the attacker has access to the database and there is absolutely nothing you can do to prevent that. In theory, there is a way Tomcat could implement. You could interactively ask for all needed passwords when starting Tomcat and keep them only in memory. httpd does that by default for encrypted SSL primary keys. But in practice the userbase that would accept the inconvenience and the impossibility to automatically start tomcat would be too small to spend time for that. And the practical security gain is small. Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 14:42, Rainer Frey wrote: On Friday 29 October 2010 15:34:29 Mark Thomas wrote: If Tomcat has access to a database and the attacker has access to a shell prompt (or similar) with the same privileges as Tomcat then the attacker has access to the database and there is absolutely nothing you can do to prevent that. In theory, there is a way Tomcat could implement. You could interactively ask for all needed passwords when starting Tomcat and keep them only in memory. httpd does that by default for encrypted SSL primary keys. But in practice the userbase that would accept the inconvenience and the impossibility to automatically start tomcat would be too small to spend time for that. And the practical security gain is small. Actually it is pretty much zero. If the password is in memory it will be in a known location and an attacker will still be able to read it (reflection, heap dump, etc). With httpd the barrier is a little higher since it is likely to be harder to find the right bit of memory. Agreed that the downtime issues far outweigh and security benefits. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
If you have a webapp where users log in you can use there login/password to login on the database. A little bit inconvenient for the DBA but you don't have passwords on your servers. Ronald. Op vrijdag, 29 oktober 2010 15:42 schreef Rainer Frey rainer.f...@inxmail.de: On Friday 29 October 2010 15:34:29 Mark Thomas wrote: If Tomcat has access to a database and the attacker has access to a shell prompt (or similar) with the same privileges as Tomcat then the attacker has access to the database and there is absolutely nothing you can do to prevent that. In theory, there is a way Tomcat could implement. You could interactively ask for all needed passwords when starting Tomcat and keep them only in memory. httpd does that by default for encrypted SSL primary keys. But in practice the userbase that would accept the inconvenience and the impossibility to automatically start tomcat would be too small to spend time for that. And the practical security gain is small. Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: running tomcat6 under a different user than root (debian)
On 29/10/2010 14:53, Ronald Klop wrote: If you have a webapp where users log in you can use there login/password to login on the database. A little bit inconvenient for the DBA but you don't have passwords on your servers. It isn't quite that clear cut. There are some trade-offs to make with this approach (and I'm not sure I like them). 1. The user's password has to be available in plain text. That prevents you from storing digested passwords in the realm. 2. All the users' passwords are in memory and that is still vulnerable to an attacker. 3. If the username/password is held in the session: a) it could get persisted to disk b) it could get replicated in a cluster both of which may, or may not, be an issue. 1 bothers me the most. For the the others, once an attacker has reached the point where they have shell access as the Tomcat user (or have some other way to extract data from the heap) then it is game over for all data that passes through that Tomcat instance. As with anything security related the right solution is going to vary from environment to environment and it is always going to involve some form of trade-off. Mark Ronald. Op vrijdag, 29 oktober 2010 15:42 schreef Rainer Frey rainer.f...@inxmail.de: On Friday 29 October 2010 15:34:29 Mark Thomas wrote: If Tomcat has access to a database and the attacker has access to a shell prompt (or similar) with the same privileges as Tomcat then the attacker has access to the database and there is absolutely nothing you can do to prevent that. In theory, there is a way Tomcat could implement. You could interactively ask for all needed passwords when starting Tomcat and keep them only in memory. httpd does that by default for encrypted SSL primary keys. But in practice the userbase that would accept the inconvenience and the impossibility to automatically start tomcat would be too small to spend time for that. And the practical security gain is small. Mark Rainer - 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
