geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Security Issue with hot deployer
Date Mon, 27 Nov 2006 09:41:22 GMT

On Nov 26, 2006, at 9:36 PM, Rakesh Midha wrote:

> I accept your point that on a non-secure machine it doesn't help to  
> have application or server level security bcoz one can anyway  
> delete file system or do lot of bad things. In that case why do we  
> have deploy tool asking for user/password even on local machine.
> My thinking is "We put locks on our home not for thiefs (anyways  
> thiefs can break locks), we put lock to stop others to not use open  
> home oportunity" What I mean to say is we dont need to make  
> applications secure on non-secure machine for felons but for  
> ourselves that we dont delete or change our applications by mistake.
> The point I was trying to make is,
> 1. We should consider thinking additing some additional security in  
> hot-deployer (there are so many illigal things which can be done,  
> but atleast our server should not facilitate them)

I still think that hot deploy should only be used in a development  
environment and since the only reason to use it is convenience,  
making it harder in any way is a bad idea.
> 2. Having an editable config file, doesn't make lot of sense from  
> security point of view, can we consider encripting it?
The main purpose of the current config file format is to make it  
reasonably easy to edit the configuration by hand.  What would  
encrypting the config file gain that would not be better served by  
appropriate OS file permissions?
> 3. Can we consider, making our repository only readable and not  
> editable from outside.
What specifically do you have in mind?  I thought that stuff like  
installing a plugin already  requires you to log into the config  
console.  Since one of the main ideas behind geronimo is to make it  
easy to assemble, extend, or contract a server, it seems to me that a  
read-only repository would create problems.

I think it would be more useful to look into authenticating that  
everything in the repo is what it claims to be.  I imagine that this  
would use either jar signing for jars or signing a hash of the jar  
file.  I don't think there is any standard way to authenticate car  
files (or car directories in a geronimo repo).  I've heard that jar  
signing tends to introduce additional problems but I don't have any  
experience with that.

Another security improvement.... not exactly a security hole.... is  
that currently some Subjects are specified completely in application  
plans, for things like default subjects and run-as subjects.  It  
would be much better if these subjects were produced by the same  
login configuration that the rest of the app is using and the plan  
had only the login info in it.  This leads onto Simon Godik's idea of  
a password safe to hold the credentials needed for these default  
logins.   I've often thought that the next step would be to require  
credentials to start the server (and unlock the password safe), but I  
haven't thought through this idea at all yet.

I might be missing the point behind your suggestions, if I have  
please explain in more detail.

david jencks

> thanks
> Rakesh
> On 11/25/06, David Jencks <> wrote:
> On Nov 25, 2006, at 9:29 AM, Aaron Mulder wrote:
> > On 11/25/06, David Jencks <> wrote:
> >> If your machine is unsecured, then people deploying rogue apps in
> >> geronimo should probably be the least of your worries.
> >>
> >> If you are still concerned about the security of the hot deployer,
> >> you should turn it off.
> >
> > Except that if the machine is really unsecured, there's little  
> you can
> > do.  You can turn the hot deployer service off but if someone  
> timed it
> > right they could edit config.xml and cause the hot deployer to start
> > next time Geronimo was started.  Or edit the accounts in the
> > administrative security realm and then just use the deploy tool.   
> You
> > could delete things from the repository but they could put them back
> > there.  Bottom line, if you're concerned about security, I think  
> your
> > app server file permissions should be locked down, regardless of  
> which
> > product you're using.
> Exactly.  I meant "If you are still concerned about the security of
> the hot deployer after thoroughly securing your machine, turn the hot
> deployer off."  I should have added, remove the hot deploy jar and
> car from your server.
> thanks
> david jencks
> >
> > Thanks,
> >     Aaron
> >
> >> On Nov 23, 2006, at 10:27 PM, Rakesh Midha wrote:
> >>
> >> > Hello
> >> >
> >> > I was wondering if this is a security breach.
> >> >
> >> > If I deploy some business critical application names myApp on
> >> > Geronimo server deployed using deploy tool or hot deployer. Now
> >> > with deploy tool I cannot change or uninstall this application
> >> > without Geronimo username and password.
> >> >
> >> > If for some reason my machine is unsecured and I am dependent on
> >> > Geronimo security, one can easily manuplate or uninstall my
> >> > application by just placing a junk application named myApp in my
> >> > hot deployer. isn't it a security breach.
> >> >
> >> > I think I should be allowed to
> >> > 1. Configure security settings for Hot deployer
> >> > 2. Start and stop hot deployment (which can be done by stopping
> >> > hotdeploy module)
> >> > 3. One way could be, All the hot deployer operations prompt for
> >> > username and password on server console.
> >> >
> >> > What is your view on this? Am I missing something?
> >> >
> >> > Thanks
> >> > Rakesh
> >> >
> >> >
> >>
> >>

View raw message