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.
thanks
david jencks
thanks
Rakesh
On 11/25/06, David Jencks <[EMAIL PROTECTED]> wrote:
On Nov 25, 2006, at 9:29 AM, Aaron Mulder wrote:
> On 11/25/06, David Jencks <[EMAIL PROTECTED]> 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
>> >
>> >
>>
>>
