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: How to start my application without localhost, only with virtiual host ?
On 29/10/2010 17:15, M.Arkhypov wrote:
Dear Chuck,
thank you for your attention and reply,
we have done a few of yours advices, but without success:
We have this server.xml file:
Host name=cntest2.de appBase=webapps
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=true
Context path=
docBase=/usr/share/tomcat6/webapps/MyNetwork
reloadable=true allowLinking=true /
/Host
If we have no path defined (path=) , there are two networks starting
Tomcat will deploy an application (either a 'app.war' file or 'app'
directory) if it finds it in the Host's configured appBase directory.
The 'appBase' is not the same an Apache HTTPD DocumentRoot directory.
(catalina.out - part)
INFO: Initializing Mojarra (1.2_12-b01-FCS) for context ''
and later
(catalina.out - part)
INFO: Initializing Mojarra (1.2_12-b01-FCS) for context '/MyNetwork'
Probably because Tomcat is deploying one instance as the ROOT
application, because you have configured the Context definition and once
for the MyNetwork directory it finds in the appBase.
we can access the page by http://cntest2.de/ - and get redirected to
http://cntest2.de/login.html.
If we define the path like path=/MyNetwork.
Host name=cntest2.de appBase=webapps
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=true
Context path=/MyNetwork
docBase=/usr/share/tomcat6/webapps/MyNetwork
reloadable=true allowLinking=true /
/Host
And starts only one network:
As Chuck tried to tell you. Do NOT define the Context in server.xml.
Please just completely remove all Context definitions from server.xml.
(catalina.out - part)
INFO: Initializing Mojarra (1.2_12-b01-FCS) for context
'/CompetenceNetwork'
The page http://cntest2.de/MyNetwork/login.html works fine.
But if we go to the page http://cntest2.de/ the index.html from ROOT is
showing.
So now we did what you said and copied the MyNetwork content (subfolder
and files) to the ROOT directory. Then we see the loginpage of MyNetwork
as expected. But now if we try to login we get URL-redirected to:
The ROOT directory is actually an application, you may have corrupted
the application by just copying over the content. It would be better to
have renamed your MyNetwork directory to become the ROOT directory.
http://cntest2.de/pages/#{subUserSessionUtil.startPageAddress}
(See below)
There is no error shown in the catalina.out, but the
#{subUserSessionUtil.startPageAddress} looks like an uninterpreted
handler call. That works if we access
the network with http://cntest2.de:8080/MyNetwork/login.html. The goal
is to access the network by its configured URL-pattern -
http://cntest2.de/login.html
(and do login etc.)
The question: how can we adjust the server.xml and work with url
http://cntest2.de/login.html , not with
http://cntest2.de/MyNetwork/login.html ?
As above. Completely remove the Context definition from server.xml.
Tnank you
conf. from apache2:
vhost_cn.conf
# Update this path to match your conf directory location (put
workers.properties next to httpd.
# JkWorkersFile /etc/tomcat6/workers.properties
# Where to put jk shared memory
# Update this path to match your local state directory or logs directory
JkShmFile /var/log/apache2/mod_jk.shm
# Where to put jk logs
#mmm:
JkWorkersFile /usr/share/tomcat6/conf/worker.properties
#
# Update this path to match your logs directory location (put
mod_jk.log next to access_log)
JkLogFile /var/log/apache2/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the timestamp log format
JkLogStampFormat [%a %b %d %H:%M:%S %Y]
NameVirtualHost *
VirtualHost *
DocumentRoot /usr/share/tomcat6/webapps/MyNetwork
*Never* map an HTTPD DocumentRoot to the same directory as a Tomcat.
It is a security risk and it will almost certainly result in your
application serving files that are not properly processed by Tomcat.
JkMount /* worker1
..
# Serve html, jpg and gif using httpd
JkUnMount /*.html ajp13
JkUnMount /*.jpg ajp13
JkUnMount /*.gif ajp13
Why use HTTPD to serve these files? Tomcat can do the job perfectly well.
If you must use HTTPD with Tomcat, arrange the directory structures so
that the two servers do not serve files from the same directory, like this:
/sites/www.foo.com/static
/sites/www.foo.com/static/images
/sites/www.foo.com/webapps/
/sites/www.foo.com/webapps/ROOT
/sites/www.foo.com/webapps/MyApplication
In httpd.conf
DocumentRoot /sites/www.foo.com/static
In server.xml:
Host name=www.foo.com appBase=/sites/www.foo.com/webapps ...
p
ServerName cntest2.de
ServerAdmin i...@cntest2.de
Directory
Re: Basic Question : Tomact Clustering
On 29/10/2010 11:49, alok kakani wrote: Hi All, I am working Business Objects 3.1(BOE) with tomcat being the application server. I am new to the web application part, hence i had some doubts We are trying to step up a BOE on 2 machines we will have tomcat installed on both machines. We plan to use MS NLB for high availability. I am not sure how will i configure the web + web apps in such scenario with Tomcat. Tomcat doesn't know what MS NLB is. Depending on how your application works and what it does, this may or may not be a suitable solution. YMMV. I will be installing tomcat 5.5 on both machines. this is shipped as default with BOE. Tomcat 6.0 should work just as well. 1. Do i need to install Apache on both machines? Apache HTTPD? No. One reason for using HTTPD is to make it the load balancer. So you would need only one HTTPD in that case. 2. What are the configuring steps to cluster tomcat for HA fail over? Read the Cluster documentation for information about what Tomcat offers: http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html 3. Do i need to cluster Apache as well?? Not if you're not using it. p Regards, *Alok Kakani* 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 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: Help on upgrade tomcat bundled with JBoss for resolving tomcat security issue -[SECURITY] CVE-2008-5515 RequestDispatcher directory traversal vulnerability
On 26/10/2010 03:42, ww...@ogcio.gov.hk wrote: Dear Sir/Madam, Recently it has been checked that there is security vulnerability for the tomcat (version 5.0.9) shipped with the JBoss 4.0.3SP1. From the link below, it is recommended to upgrade to 5.5.28. http://marc.info/?l=tomcat-userm=124449799021571w=2 We have tried to upgrade the some tomcat library for version 5.5.31 by following with the steps we found in the web in http://itapproaches.blogspot.com/2010/08/upgrading-tomcat-in-jboss-405.html Yet we have encountered the exception (as attached for your reference). Should we upgrade the tomcat only, without upgrading the JBoss AS? This question is probably better addressed to JBoss support. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Tomcat 6.0.29: Failed to initialize the SSLEngine
On 06/10/2010 17:20, Samuel Hofer wrote: Hi, I'm trying to install Apache Tomcat 6.0.29 on a Debian GNU/Linux 5.0.4 32bit with kernel release 2.6.26-2-686 with APR and SSL. JDK 1.6.0_21 APR 1.2.9 OpenSSL 0.9.8 There seems to be a problem with the Tomcat Native library 1.1.20: 06.10.2010 15:02:51 org.apache.catalina.core.AprLifecycleListener init FEIN: Loaded APR based Apache Tomcat Native library 1.1.20. 06.10.2010 15:02:51 org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 06.10.2010 15:02:51 org.apache.catalina.core.AprLifecycleListener lifecycleEvent FEIN: Failed to initialize the SSLEngine. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleList ener.java:238) at org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleLis tener.java:97) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:119) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:770) at org.apache.catalina.startup.Catalina.load(Catalina.java:524) at org.apache.catalina.startup.Catalina.load(Catalina.java:548) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:261) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: org.apache.tomcat.jni.Error: This function has not been implemented on this platform at org.apache.tomcat.jni.SSL.initialize(Native Method) ... 16 more 06.10.2010 15:02:51 org.apache.coyote.http11.Http11AprProtocol init How can I solve this problem? If your APR really is 1.2.9, then I suspect that you need to upgrade your APR to a newer version. Version 1.4.2 was released 2010-04-04. I would also recommend that you check that you are using the best available version of OpenSSL, and then recompile Tomcat Native. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Tomcat 6.0.29: Failed to initialize the SSLEngine
On 30/10/2010 11:49, Pid wrote: How can I solve this problem? If your APR really is 1.2.9, then I suspect that you need to upgrade your APR to a newer version. Version 1.4.2 was released 2010-04-04. APR is not the problem here. If it were then it wouldn't load at all. I would also recommend that you check that you are using the best available version of OpenSSL, and then recompile Tomcat Native. The point is to use the system provided OpenSSL. O.9.8 will work just fine. However how he get the Tomcat Native binaries is the real question. 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)
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: Tomcat Maven and Axis 1.5.1 problem
to solve will need web.xml all .jsp *.wsdl all java files Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sat, 30 Oct 2010 10:56:14 +0100 From: p...@pidster.com To: users@tomcat.apache.org Subject: Re: Tomcat Maven and Axis 1.5.1 problem On 29/10/2010 08:25, srd.pl wrote: Thanks for the contribution. I have posted on the axis list but no response and I'm running out of time :/ If you can take a look at a list of the .jar files my webservice has: Do you have all of these jars in the web app? If so, why? Do you really need all of the ant AND maven jars in your webapp? You have two lots of JavaMail JAF (the first jar below and the geronimo jars. Duplicate jars may lead to problems and is unnecessary. It's impossible to know what's wrong with your application, based on the information you've provided so far. p activation-1.1.jar ant-1.7.0.jar ant-launcher-1.7.0.jar antlr-2.7.6.jar apache-maven-2.0.9.jar asm-3.1.jar asm-attrs-1.5.3.jar axiom-api-1.2.8.jar axiom-dom-1.2.8.jar axiom-impl-1.2.8.jar axis-wsdl4j-1.5.1.jar axis2-1.5.1.jar axis2-adb-1.5.1.jar axis2-adb-codegen-1.5.1.jar axis2-codegen-1.5.1.jar axis2-kernel-1.5.1.jar axis2-wsdl2code-maven-plugin-1.5.1.jar axis2-xmlbeans-1.5.1.jar cglib-nodep-2.2.jar classworlds-1.1-alpha-2.jar commons-cli-1.0.jar commons-codec-1.2.jar commons-collections-3.2.1.jar commons-fileupload-1.2.jar commons-httpclient-3.1.jar commons-io-1.4.jar commons-logging-1.1.1.jar dom4j-1.6.1.jar doxia-sink-api-1.0-alpha-10.jar ehcache-1.2.3.jar geronimo-activation_1.1_spec-1.0.1.jar geronimo-javamail_1.4_spec-1.2.jar geronimo-javamail_1.4_spec-1.6.jar geronimo-jta_1.1_spec-1.1.jar geronimo-stax-api_1.0_spec-1.0.1.jar geronimo-ws-metadata_2.0_spec-1.1.2.jar hibernate-3.2.7.ga.jar jaxb-api-2.2.1.jar jaxb-impl-2.2.1.1.jar jaxen-1.1.1.jar jdom-1.0.jar jersey-bundle-1.3.jar jersey-client-1.3.jar jersey-core-1.3.jar jersey-multipart-1.3.jar jsch-0.1.27.jar jsr311-api-1.1.1.jar jtidy-4aug2000r7-dev.jar log4j-1.2.14.jar mail-1.4.jar maven-artifact-2.0.8.jar maven-artifact-manager-2.0.7.jar maven-core-2.0.9.jar maven-error-diagnostics-2.0.9.jar maven-model-2.0.7.jar maven-monitor-2.0.9.jar maven-plugin-api-2.0.7.jar maven-plugin-descriptor-2.0.9.jar maven-plugin-parameter-documenter-2.0.9.jar maven-plugin-registry-2.0.7.jar maven-profile-2.0.7.jar maven-project-2.0.7.jar maven-reporting-api-2.0.9.jar maven-repository-metadata-2.0.7.jar maven-settings-2.0.7.jar maven-toolchain-2.0.9.jar maven-wadl-plugin-1.3.jar mimepull-1.4.jar neethi-2.0.4.jar plexus-container-default-1.0-alpha-9-stable-1.jar plexus-interactivity-api-1.0-alpha-4.jar plexus-utils-1.4.9.jar servlet-api-2.3.jar slf4j-api-1.5.11.jar slf4j-log4j12-1.5.11.jar slide-webdavlib-2.1.jar stax-api-1.0-2.jar wagon-file-1.0-beta-2.jar wagon-http-lightweight-1.0-beta-2.jar wagon-http-shared-1.0-beta-2.jar wagon-provider-api-1.0-beta-2.jar wagon-ssh-1.0-beta-2.jar wagon-ssh-common-1.0-beta-2.jar wagon-ssh-external-1.0-beta-2.jar wagon-webdav-1.0-beta-2.jar woden-api-1.0M8.jar woden-impl-dom-1.0M8.jar wsdl4j-1.6.2.jar wstx-asl-3.2.4.jar xalan-2.7.0.jar xercesImpl-2.6.1.jar xml-apis-1.0.b2.jar xml-apis-1.3.04.jar xml-im-exporter-1.1.jar xmlbeans-2.3.0.jar xmlParserAPIs-2.6.0.jar XmlSchema-1.4.3.jar And this is my pom.xml file: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.mywebapp/groupId artifactIdWebApp/artifactId packagingwar/packaging nameWebApplication for Axis 2/name version0.1/version dependencies dependency groupIdorg.apache.tomcat/groupId
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
