geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Constructing deployment plans from Configuration GBeanData
Date Fri, 18 Nov 2005 20:16:47 GMT

On Nov 18, 2005, at 11:05 AM, Kevan Miller wrote:

> On 11/18/05, Aaron Mulder <> wrote:
> On 11/18/05, Dain Sundstrom <> wrote:
> > Wait a sec.  We are worried about an administrator that has  
> access to
> > the console from seeing a password embedded an a configuration file?
> > The admin can deploy applications, which could easily just scan for
> > passwords in memory or on disk.  Anyone with access to this console
> > is "root" for the geronimo instance.
> Yeah, that's why I waffle.  But for example, if you look at a database
> pool in the console, it uses a password field and doesn't show you the
> plain text.  It's not that you can't get around this (via, say, view
> source, if not writing your own code to inspect the GBeans), it's that
> I'm not sure I like flagrantly popping up stuff with passwords right
> there.  You know, shoulder-surfing, or whatever.
> Erin says some peolpe argue that no security is better than something
> weak that gives you a false sense of security, but I also think
> there's a place for defending against the casual observer.
> Forget about the console for a sec.  How many people will think to
> make their config store directory non-world-readable?  Sure you could
> write some code to deserialize the stuff in there today, but if anyone
> with an account on the box can just view a plain-text plan out of the
> config store with the passwords, that's really "no security".  (And
> since every connector has different config params it's not so easy to
> just mask out the password in every file we copy in there, though it
> would be a good start to do it for any config-param where
> name.toLowerCase().indexOf("password") > -1.)
> Aaron
> I think you raise a couple of good points about 1) protecting  
> config-store directory and 2) masking sensitive configuration data.  
> I ran into both of these looking at your recent issue
> (keystore and  
> passstore passwords are available in System properties).
> BTW, another potential exposure of sensitive data are the admin ids  
> and passwords stored in a .geronimo-deployer directory by your  
> recent "login" addition to deployer.
> config-store and .geronimo-deployer are documentation/good practice  
> issues which shouldn't be too hard to document (but easy to ignore/ 
> miss...). Protecting sensitive data in the runtime seems like a  
> harder task. Something we can address in V1? Something we must  
> address in V1? Any other security-related problems?

In 1.1+ we could change the config store to set the file permissions  
on the directories it creates.


View raw message