geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Constructing deployment plans from Configuration GBeanData
Date Fri, 18 Nov 2005 19:05:40 GMT
On 11/18/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>
> On 11/18/05, Dain Sundstrom <dain@iq80.com> 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
 http://issues.apache.org/jira/browse/GERONIMO-1135 (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?

--kevan

> On Nov 18, 2005, at 8:57 AM, Dain Sundstrom wrote:
> > > If we are the ones copying over the plans, why not have the
> > > deployment code for the module, simply remove passwords from the
> > > file before copying it. Alternatively, we could choose to not copy
> > > over the plan for connectors.
> > >
> > > -dain
> > >
> > > On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
> > >
> > >> Note that JSR-77 requires us to expose the J2EE DD through our module
> > >> beans, and it may make sense to provide a similar hook for the
> > >> Geronimo plan. That would make it easy to implement nicely in the
> > >> console, certainly.
> > >>
> > >> However, I agree that it's important to be able to suppress showing
> > >> plans, particular for connectors where they're likely to have
> > >> passwords in them. Sure, you only see that if you got into the
> > >> console/MEJB/whatever to begin with, but still... I'm not sure what
> > >> to say about the default behavior. I thought this was such a cool
> > >> idea until I thought about the password issue, but if we make hiding
> > >> the plans the default, then it's not all that useful a feature. I'm
> > >> waffling.
> > >>
> > >> Aaron
> > >>
> > >> On 11/18/05, David Jencks < david_jencks@yahoo.com> wrote:
> > >>>
> > >>> On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>> On 11/17/05, David Jencks < david_jencks@yahoo.com> wrote:
> > >>>>> On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
> > >>>>>
> > >>>>>> If deployment plans are inside the archive (ear, war, etc.)
> > >>>>>> they can
> > >>>>>> be obtained from config-store. If the deployment plan is
> > >>>>>> supplied as
> > >>>>>> an external file to the deployer and if the original file
is not
> > >>>>>> available, the only way to get any information on the
> > >>>>>> configuration
> > >>>>> is
> > >>>>>> from the Configuration GBeanData obtained from the kernel
at
> > >>>>>> runtime
> > >>>>>> or from deserializing config.ser files under config-store.
For
> > >>>>>> analyzing any problems after an application is deployed,
> > >>>>>> deployment
> > >>>>>> plans will certainly be helpful.
> > >>>>>
> > >>>>> If you think this is really valuable information, I think a
better
>
> > >>>>> approach is to store the plan(s) in a known location in the
> > >>>>> configuration so they may be retrieved directly.
> > >>>> I thought of this as an option because it will really simplify
> > >>>> a lot
> > >>>> of things, and I can avoid writing a configuration decompiler :o).
> > >>>> But, then will there be any instances where the user will not
> > >>>> want the
> > >>>> deployment plan to be stored in the server as is? Will "not want
to
> > >>>> store the deployment plan in the config-store" be ever a users'
> > >>>> reason
> > >>>> for supplying deployment plan as an external file to the deployer?
> > >>>
> > >>> Well, I think there will be few cases where the original deployment
> > >>> plan will be unavailable from other sources, and I don't
> > >>> particularly
> > >>> like including it in the configuration. However, I don't think this
> > >>> has much to do with the desirability of keeping the plan separate
> > >>> from
> > >>> the module you are deploying: I think this is always a good
> > >>> idea. I do
> > >>> think that some people will want to conceal their plan and if we do
> > >>> provide a way to include it in the configuration this choice must be
>
> > >>> optional.
> > >>>
> > >>> thanks
> > >>> david jencks
> > >>>
> > >>>
> >
> >
>

Mime
View raw message