Clustering Tomcat - StandardManager loaded instead of DeltaManager

[Petr Skokan]

Hi All,

I am trying to configure Tomcat for cluster in Tomcat 6.

However in the catalina.out tomcat is still creating StandardManager
instead of defined DeltaManager:

Any suggestion what is wrong here ??

Thanks,

Petr.


Here is catalina.out after start:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
May 13, 2008 3:57:25 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
start
INFO: Cluster is about to start
May 13, 2008 3:57:25 PM
org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/192.168.40.13:5001
May 13, 2008 3:57:25 PM
org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
May 13, 2008 3:57:25 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership,
start level:4
May 13, 2008 3:57:26 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:4
May 13, 2008 3:57:26 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership,
start level:8
May 13, 2008 3:57:27 PM
org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:8
May 13, 2008 3:57:27 PM
org.apache.catalina.ha.session.JvmRouteBinderValve start
INFO: JvmRouteBinderValve started
May 13, 2008 3:57:28 PM org.apache.catalina.core.StandardContext
addApplicationListener
INFO: The listener "com.mgmtp.sec.servlet.Context" is already configured
for this context. The duplicate definition has been ignored.
May 13, 2008 3:57:28 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
registerManager
WARNING: Manager [ org.apache.catalina.session.StandardManager@6cd24e3f]
does not implement ClusterManager, addition to cluster has been aborted.


server.xml <Cluster> definition is here:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">

<Manager className="org.apache.catalina.ha.session.DeltaManager"
 expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>

    <Channel className="org.apache.catalina.tribes.group.GroupChannel">
        <Membership
className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>

<Receiver
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="5001"
                      selectorTimeout="100"
                      maxThreads="6"/>

            <Sender
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
            <Interceptor
className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
        </Channel>

          <Valve
className="org.apache.catalina.ha.tcp.ReplicationValve"/>
          <Valve
className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>


<ClusterListener
className="org.apache.catalina.ha.session.ClusterSessionListener"/>

</Cluster>


---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Filip Hanik - Dev Lists]

do you by any chance have the <Manager> element uncommented in
conf/context.xml or haven't set <distributable/> in your web.xml

Filip

Petr Skokan wrote:

> Hi All,
>
> I am trying to configure Tomcat for cluster in Tomcat 6.
>
> However in the catalina.out tomcat is still creating StandardManager
> instead of defined DeltaManager:
>
> Any suggestion what is wrong here ??
>
> Thanks,
>
> Petr.
>
>
> Here is catalina.out after start:
>
> INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
> May 13, 2008 3:57:25 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> start
> INFO: Cluster is about to start
> May 13, 2008 3:57:25 PM
> org.apache.catalina.tribes.transport.ReceiverBase bind
> INFO: Receiver Server Socket bound to:/192.168.40.13:5001
> May 13, 2008 3:57:25 PM
> org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
> INFO: Setting cluster mcast soTimeout to 500
> May 13, 2008 3:57:25 PM
> org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> INFO: Sleeping for 1000 milliseconds to establish cluster membership,
> start level:4
> May 13, 2008 3:57:26 PM
> org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> INFO: Done sleeping, membership established, start level:4
> May 13, 2008 3:57:26 PM
> org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> INFO: Sleeping for 1000 milliseconds to establish cluster membership,
> start level:8
> May 13, 2008 3:57:27 PM
> org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> INFO: Done sleeping, membership established, start level:8
> May 13, 2008 3:57:27 PM
> org.apache.catalina.ha.session.JvmRouteBinderValve start
> INFO: JvmRouteBinderValve started
> May 13, 2008 3:57:28 PM org.apache.catalina.core.StandardContext
> addApplicationListener
> INFO: The listener "com.mgmtp.sec.servlet.Context" is already configured
> for this context. The duplicate definition has been ignored.
> May 13, 2008 3:57:28 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> registerManager
> WARNING: Manager [ org.apache.catalina.session.StandardManager@6cd24e3f]
> does not implement ClusterManager, addition to cluster has been aborted.
>
>
> server.xml <Cluster> definition is here:
>
> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>
> <Manager className="org.apache.catalina.ha.session.DeltaManager"
>  expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
>
>     <Channel className="org.apache.catalina.tribes.group.GroupChannel">
>         <Membership
> className="org.apache.catalina.tribes.membership.McastService"
>                         address="228.0.0.4"
>                         port="45564"
>                         frequency="500"
>                         dropTime="3000"/>
>
> <Receiver
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>                       address="auto"
>                       port="5001"
>                       selectorTimeout="100"
>                       maxThreads="6"/>
>
>             <Sender
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>               <Transport
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
>             </Sender>
>             <Interceptor
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>             <Interceptor
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>             <Interceptor
> className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
>         </Channel>
>
>           <Valve
> className="org.apache.catalina.ha.tcp.ReplicationValve"/>
>           <Valve
> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>
> <ClusterListener
> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>
> </Cluster>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>  

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Petr Skokan]

Hi Filip,

I already found that - because to disable session persistency there is a
"hint" in Tomcat pages to uncomment that <Manager path=""/> and this was
causing a trouble as somebody uncomented that...

Regards,

Petr.


On Tue, 2008-05-13 at 07:46 -0700, Filip Hanik - Dev Lists wrote:

> do you by any chance have the <Manager> element uncommented in
> conf/context.xml or haven't set <distributable/> in your web.xml
>
> Filip
>
> Petr Skokan wrote:
> > Hi All,
> >
> > I am trying to configure Tomcat for cluster in Tomcat 6.
> >
> > However in the catalina.out tomcat is still creating StandardManager
> > instead of defined DeltaManager:
> >
> > Any suggestion what is wrong here ??
> >
> > Thanks,
> >
> > Petr.
> >
> >
> > Here is catalina.out after start:
> >
> > INFO: Starting Servlet Engine: Apache Tomcat/6.0.16
> > May 13, 2008 3:57:25 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> > start
> > INFO: Cluster is about to start
> > May 13, 2008 3:57:25 PM
> > org.apache.catalina.tribes.transport.ReceiverBase bind
> > INFO: Receiver Server Socket bound to:/192.168.40.13:5001
> > May 13, 2008 3:57:25 PM
> > org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
> > INFO: Setting cluster mcast soTimeout to 500
> > May 13, 2008 3:57:25 PM
> > org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> > INFO: Sleeping for 1000 milliseconds to establish cluster membership,
> > start level:4
> > May 13, 2008 3:57:26 PM
> > org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> > INFO: Done sleeping, membership established, start level:4
> > May 13, 2008 3:57:26 PM
> > org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> > INFO: Sleeping for 1000 milliseconds to establish cluster membership,
> > start level:8
> > May 13, 2008 3:57:27 PM
> > org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
> > INFO: Done sleeping, membership established, start level:8
> > May 13, 2008 3:57:27 PM
> > org.apache.catalina.ha.session.JvmRouteBinderValve start
> > INFO: JvmRouteBinderValve started
> > May 13, 2008 3:57:28 PM org.apache.catalina.core.StandardContext
> > addApplicationListener
> > INFO: The listener "com.mgmtp.sec.servlet.Context" is already configured
> > for this context. The duplicate definition has been ignored.
> > May 13, 2008 3:57:28 PM org.apache.catalina.ha.tcp.SimpleTcpCluster
> > registerManager
> > WARNING: Manager [ org.apache.catalina.session.StandardManager@6cd24e3f]
> > does not implement ClusterManager, addition to cluster has been aborted.
> >
> >
> > server.xml <Cluster> definition is here:
> >
> > <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
> >
> > <Manager className="org.apache.catalina.ha.session.DeltaManager"
> >  expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
> >
> >     <Channel className="org.apache.catalina.tribes.group.GroupChannel">
> >         <Membership
> > className="org.apache.catalina.tribes.membership.McastService"
> >                         address="228.0.0.4"
> >                         port="45564"
> >                         frequency="500"
> >                         dropTime="3000"/>
> >
> > <Receiver
> > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> >                       address="auto"
> >                       port="5001"
> >                       selectorTimeout="100"
> >                       maxThreads="6"/>
> >
> >             <Sender
> > className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> >               <Transport
> > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> >             </Sender>
> >             <Interceptor
> > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> >             <Interceptor
> > className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> >             <Interceptor
> > className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
> >         </Channel>
> >
> >           <Valve
> > className="org.apache.catalina.ha.tcp.ReplicationValve"/>
> >           <Valve
> > className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
> >
> >
> > <ClusterListener
> > className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> >
> > </Cluster>
> >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@...
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> >  
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Milanez, Marcus]

Hello everyove,

We were asked to eliminate clear text passwords associated to database
pooled connections in context.xml files... I know it has been discussed
a lot, but I would like to ask once again whether someone has a simple,
clean solution for that. We are using Windows server and MS SQL 2005.
One of the options I came across is to use Windows Integratd
authentication instead of database users. Is there any other ideas to
overcome this situation?

Thanks a lot,

Marcus Milanez

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Filip Hanik - Dev Lists]

it's a wasted effort, the one way it could be truly secure, was if
tomcat asked you for a key upon startup. this wouldn't work very well in
a 1000 tomcat instance server farm.

any other effort simply masks the problem, letting you think it is
secure, when it isn't.

what you should do is this
1. make sure tomcat runs as an account that can't login
2. make any file that contains secure information readonly, and readable
only by the tomcat user

if someone gets onto your machine as an super user, you have bigger
problem than the password being in clear text

Filip

Milanez, Marcus wrote:

> Hello everyove,
>
> We were asked to eliminate clear text passwords associated to database
> pooled connections in context.xml files... I know it has been discussed
> a lot, but I would like to ask once again whether someone has a simple,
> clean solution for that. We are using Windows server and MS SQL 2005.
> One of the options I came across is to use Windows Integratd
> authentication instead of database users. Is there any other ideas to
> overcome this situation?
>
> Thanks a lot,
>
> Marcus Milanez
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>  

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Milanez, Marcus]

Filip thanks for your reply,

>> 1. make sure tomcat runs as an account that can't login
Right, that is done

>> 2. make any file that contains secure information readonly, and readable only by the tomcat user
Done too


>> if someone gets onto your machine as an super user, you have bigger problem than the password being in clear text

That is the answer everyone gives in tomcat forums all over the internet, so it seems to me that no possible solution is available. On the other hand, is it right to stay behind a possible security fault (malicious super user performing login) in order to say I'll not correct known security issues in my application? The thing is I'm not responsible for the servers but the ones who are, keep arguing that this is a crictical security problem. Are they seeing a big problem in a small one?

Thanks a lot!

Marcus




-----Mensagem original-----
De: Filip Hanik - Dev Lists [mailto:devlists@...]
Enviada em: terça-feira, 13 de maio de 2008 12:37
Para: Tomcat Users List
Assunto: Re: Once again, clear text passwords in context.xml files

it's a wasted effort, the one way it could be truly secure, was if tomcat asked you for a key upon startup. this wouldn't work very well in a 1000 tomcat instance server farm.

any other effort simply masks the problem, letting you think it is secure, when it isn't.

what you should do is this
1. make sure tomcat runs as an account that can't login 2. make any file that contains secure information readonly, and readable only by the tomcat user

if someone gets onto your machine as an super user, you have bigger problem than the password being in clear text

Filip

Milanez, Marcus wrote:

> Hello everyove,
>
> We were asked to eliminate clear text passwords associated to database
> pooled connections in context.xml files... I know it has been
> discussed a lot, but I would like to ask once again whether someone
> has a simple, clean solution for that. We are using Windows server and MS SQL 2005.
> One of the options I came across is to use Windows Integratd
> authentication instead of database users. Is there any other ideas to
> overcome this situation?
>
> Thanks a lot,
>
> Marcus Milanez
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@... To unsubscribe,
> e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
>  

---------------------------------------------------------------------
To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[NetKev]

How about hashing the passwords with a known forumla and storing them
in this intermediate format.  App would need to hash the user input
and compare.  This might give ur security czars a warmer feeling and
get them off ur back.

-Kevin



On 5/13/08, Milanez, Marcus <Marcus.Milanez@...> wrote:

> Filip thanks for your reply,
>
> >> 1. make sure tomcat runs as an account that can't login
> Right, that is done
>
> >> 2. make any file that contains secure information readonly, and readable
> only by the tomcat user
> Done too
>
>
> >> if someone gets onto your machine as an super user, you have bigger
> problem than the password being in clear text
>
> That is the answer everyone gives in tomcat forums all over the internet, so
> it seems to me that no possible solution is available. On the other hand, is
> it right to stay behind a possible security fault (malicious super user
> performing login) in order to say I'll not correct known security issues in
> my application? The thing is I'm not responsible for the servers but the
> ones who are, keep arguing that this is a crictical security problem. Are
> they seeing a big problem in a small one?
>
> Thanks a lot!
>
> Marcus
>
>
>
>
> -----Mensagem original-----
> De: Filip Hanik - Dev Lists [mailto:devlists@...]
> Enviada em: terça-feira, 13 de maio de 2008 12:37
> Para: Tomcat Users List
> Assunto: Re: Once again, clear text passwords in context.xml files
>
> it's a wasted effort, the one way it could be truly secure, was if tomcat
> asked you for a key upon startup. this wouldn't work very well in a 1000
> tomcat instance server farm.
>
> any other effort simply masks the problem, letting you think it is secure,
> when it isn't.
>
> what you should do is this
> 1. make sure tomcat runs as an account that can't login 2. make any file
> that contains secure information readonly, and readable only by the tomcat
> user
>
> if someone gets onto your machine as an super user, you have bigger problem
> than the password being in clear text
>
> Filip
>
> Milanez, Marcus wrote:
> > Hello everyove,
> >
> > We were asked to eliminate clear text passwords associated to database
> > pooled connections in context.xml files... I know it has been
> > discussed a lot, but I would like to ask once again whether someone
> > has a simple, clean solution for that. We are using Windows server and MS
> SQL 2005.
> > One of the options I came across is to use Windows Integratd
> > authentication instead of database users. Is there any other ideas to
> > overcome this situation?
> >
> > Thanks a lot,
> >
> > Marcus Milanez
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@... To unsubscribe,
> > e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@... To unsubscribe,
> e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
-Kevin
---------
If you forward this e-mail to someone else, please remove my e-mail
address to help me prevent spam.  Thanks!

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Caldarale, Charles R]

> From: Kevin Williams [mailto:kevin@...]
> Subject: Re: Once again, clear text passwords in context.xml files
>
> How about hashing the passwords with a known forumla and storing them
> in this intermediate format.  App would need to hash the user input
> and compare.

There's no user input.  The passwords under discussion are those used by
Tomcat itself to establish access to a resource such as a data base.

 - 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 start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Milanez, Marcus]

Hi kevin,

Thnaks a lot for your answer, but there is no user input. The password is for database access porpuses and is stored in context.xml file...

It seems to me there is no solution at all for this issue, unless beleive server access are safe...

Thank you!

Marcus

-----Mensagem original-----
De: Kevin Williams [mailto:kevin@...]
Enviada em: terça-feira, 13 de maio de 2008 14:36
Para: Tomcat Users List
Assunto: Re: Once again, clear text passwords in context.xml files

How about hashing the passwords with a known forumla and storing them in this intermediate format.  App would need to hash the user input and compare.  This might give ur security czars a warmer feeling and get them off ur back.

-Kevin



On 5/13/08, Milanez, Marcus <Marcus.Milanez@...> wrote:

> Filip thanks for your reply,
>
> >> 1. make sure tomcat runs as an account that can't login
> Right, that is done
>
> >> 2. make any file that contains secure information readonly, and
> >> readable
> only by the tomcat user
> Done too
>
>
> >> if someone gets onto your machine as an super user, you have bigger
> problem than the password being in clear text
>
> That is the answer everyone gives in tomcat forums all over the
> internet, so it seems to me that no possible solution is available. On
> the other hand, is it right to stay behind a possible security fault
> (malicious super user performing login) in order to say I'll not
> correct known security issues in my application? The thing is I'm not
> responsible for the servers but the ones who are, keep arguing that
> this is a crictical security problem. Are they seeing a big problem in a small one?
>
> Thanks a lot!
>
> Marcus
>
>
>
>
> -----Mensagem original-----
> De: Filip Hanik - Dev Lists [mailto:devlists@...] Enviada em:
> terça-feira, 13 de maio de 2008 12:37
> Para: Tomcat Users List
> Assunto: Re: Once again, clear text passwords in context.xml files
>
> it's a wasted effort, the one way it could be truly secure, was if
> tomcat asked you for a key upon startup. this wouldn't work very well
> in a 1000 tomcat instance server farm.
>
> any other effort simply masks the problem, letting you think it is
> secure, when it isn't.
>
> what you should do is this
> 1. make sure tomcat runs as an account that can't login 2. make any
> file that contains secure information readonly, and readable only by
> the tomcat user
>
> if someone gets onto your machine as an super user, you have bigger
> problem than the password being in clear text
>
> Filip
>
> Milanez, Marcus wrote:
> > Hello everyove,
> >
> > We were asked to eliminate clear text passwords associated to
> > database pooled connections in context.xml files... I know it has
> > been discussed a lot, but I would like to ask once again whether
> > someone has a simple, clean solution for that. We are using Windows
> > server and MS
> SQL 2005.
> > One of the options I came across is to use Windows Integratd
> > authentication instead of database users. Is there any other ideas
> > to overcome this situation?
> >
> > Thanks a lot,
> >
> > Marcus Milanez
> >
> > --------------------------------------------------------------------
> > - To start a new topic, e-mail: users@... To
> > unsubscribe,
> > e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@... To unsubscribe,
> e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@... To unsubscribe,
> e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
-Kevin
---------
If you forward this e-mail to someone else, please remove my e-mail address to help me prevent spam.  Thanks!

---------------------------------------------------------------------
To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[David Smith-2]

Kevin:
That works for remote user accounts logging into tomcat webapps, but
does not work for database pools, etc., ... where tomcat the service has
to perform a login to gain access to protected resources.

Marcus:
If the admins who are making noise ever really thought about the
problem, they would know better.  You could hash the passwords, but then
there would have to be some code somewhere to unhash them with
potentially yet another password to unhash that.  And if you don't
unhash the password before using it to access the resource, it's the
same as a clear text password.  You really never get away from having a
password of some form sitting around somewhere.

Besides, have you ever asked them how they handle the private key for
their SSL certificate?  That has to sit on the server in the clear.  
It's certainly not encoded in any way that would stop a hacker and I
would argue it's more important to keep that safe than the password your
webapp uses to access protected resources.

Regarding malicious superuser, if they let an untrusted party gain that
level of access on their server they have *MUCH* bigger problems than
your tomcat service.

Tomcat should only be using accounts with minimum access rights anyway
(as we all should if you really want to get down to best practice).  And
if the resource is of a sensitive nature, it should be behind a firewall
limiting availability to the outside world.

--David

Kevin Williams wrote:

> How about hashing the passwords with a known forumla and storing them
> in this intermediate format.  App would need to hash the user input
> and compare.  This might give ur security czars a warmer feeling and
> get them off ur back.
>
> -Kevin
>
>
>
> On 5/13/08, Milanez, Marcus <Marcus.Milanez@...> wrote:
>  
>> Filip thanks for your reply,
>>
>>    
>>>> 1. make sure tomcat runs as an account that can't login
>>>>        
>> Right, that is done
>>
>>    
>>>> 2. make any file that contains secure information readonly, and readable
>>>>        
>> only by the tomcat user
>> Done too
>>
>>
>>    
>>>> if someone gets onto your machine as an super user, you have bigger
>>>>        
>> problem than the password being in clear text
>>
>> That is the answer everyone gives in tomcat forums all over the internet, so
>> it seems to me that no possible solution is available. On the other hand, is
>> it right to stay behind a possible security fault (malicious super user
>> performing login) in order to say I'll not correct known security issues in
>> my application? The thing is I'm not responsible for the servers but the
>> ones who are, keep arguing that this is a crictical security problem. Are
>> they seeing a big problem in a small one?
>>
>> Thanks a lot!
>>
>> Marcus
>>
>>
>>
>>
>> -----Mensagem original-----
>> De: Filip Hanik - Dev Lists [mailto:devlists@...]
>> Enviada em: terça-feira, 13 de maio de 2008 12:37
>> Para: Tomcat Users List
>> Assunto: Re: Once again, clear text passwords in context.xml files
>>
>> it's a wasted effort, the one way it could be truly secure, was if tomcat
>> asked you for a key upon startup. this wouldn't work very well in a 1000
>> tomcat instance server farm.
>>
>> any other effort simply masks the problem, letting you think it is secure,
>> when it isn't.
>>
>> what you should do is this
>> 1. make sure tomcat runs as an account that can't login 2. make any file
>> that contains secure information readonly, and readable only by the tomcat
>> user
>>
>> if someone gets onto your machine as an super user, you have bigger problem
>> than the password being in clear text
>>
>> Filip
>>
>> Milanez, Marcus wrote:
>>    
>>> Hello everyove,
>>>
>>> We were asked to eliminate clear text passwords associated to database
>>> pooled connections in context.xml files... I know it has been
>>> discussed a lot, but I would like to ask once again whether someone
>>> has a simple, clean solution for that. We are using Windows server and MS
>>>      
>> SQL 2005.
>>    
>>> One of the options I came across is to use Windows Integratd
>>> authentication instead of database users. Is there any other ideas to
>>> overcome this situation?
>>>
>>> Thanks a lot,
>>>
>>> Marcus Milanez
>>>
>>>      

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Crowther]

> From: Milanez, Marcus [mailto:Marcus.Milanez@...]
> On the other hand, is it right to stay behind a
> possible security fault (malicious super user performing
> login) in order to say I'll not correct known security issues
> in my application?

There's a lovely discussion on exactly this topic in Howard and LeBlanc, "Writing Secure Code".  The conclusion is that you don't need to make this bombproof, but you do need to ensure it's not the weakest link in the security chain.  A relatively simple approach, such as obfuscating the password, would probably defeat the typical script kiddie who grabs a kit to exploit a vulnerability on the server and manages to get in as root.  It wouldn't defeat a determined cracker.  It probably *would* defeat the disgruntled sysadmin who decides to leave the company with some secrets and sell them / break the systems - and remember that "inside jobs" like that are a significant fraction of all security breaches.

I'd ask broader questions: What is the organisation's security policy?  What threat analysis has been done on the application?  Is this the weakest link / does it not meet policy?  If so, how much stronger does it need to be in order to be "sufficiently good" to meet the organisation's security policy?

                - Peter

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcus,

Milanez, Marcus wrote:
| Filip Hanik wrote:
|> if someone gets onto your machine as an super user, you have bigger
|> problem than the password being in clear text
|
| That is the answer everyone gives in tomcat forums all over the
| internet, so it seems to me that no possible solution is available.

Possible solutions exist... it's just that nobody on the Tomcat team has
implemented any of those solutions in the main code base. You are free
to write your own classes that plug-into Tomcat to read, say, a
3DES-encrypted password with a known passphrase (which must be in the
clear, by the way) and use that for your database connections. You could
also use no password, in which case there's no sensitive information in
the context.xml file ;)

| On the other hand, is it right to stay behind a possible security
| fault (malicious super user performing login) in order to say I'll
| not correct known security issues in my application?

The admin needs to have the password somehow. Or, the password to the
password. Or, the password to the password to the ...

| The thing is I'm not responsible for the servers but the ones who
| are, keep arguing that this is a critical security problem. Are they
| seeing a big problem in a small one?

If your admins see this as a critical security problem, tell them to go
out and find another Java application server that doesn't have the same
issue.

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgq8y0ACgkQ9CaO5/Lv0PCYfQCeMsFlR3jWFWANiZYnN3n4YEIQ
uVcAn1vwQ1kWLjrs+Kx89R3HAKI0EU9/
=p7eQ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...