db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: SecurityManager incompatibility (was Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade)
Date Fri, 01 Jun 2007 18:41:53 GMT
Rick Hillegas wrote:
> Thanks to Dan and David for your advice. Some more musings follow:
> 
> David Van Couvering wrote:
>> I am also torn between 2 and 3 but am leaning towards 2, especially if
>> we document this is what we should do.
>>
>> Does Derby 10.3 have a beta period?  If we can get a strong amount of
>> users testing Derby 10.3 in beta we might get some good feedback if we
>> go with option 2.  If we start with 3 from the get-go,  nobody would
>> give us feedback (as it continues to work the way it did in 10.2), but
>> we could be complicit in letting users expose themselves in a
>> dangerous way.
> Our release process doesn't factor in what I would call a beta test. To 
> my way of thinking, a real beta program would require a lot of 
> preparation, which we haven't done, and a lot of monitoring, which we 
> haven't planned.
> 
> In short, I don't think our release process will give you the feedback 
> you want here. Possibly we would get quick, negative feedback that (2) 
> is the wrong approach. But I don't think we'll get sufficient feedback 
> to feel confident that (2) is the right approach.
>>
>> Like I said, if you're making your DB available on machines other than
>> localhost, you are running in a non-development mode.  I imagine the
>> following scenario where I am your standard IT guy eating donuts in
>> the server room:
>>
>> - I upgrade to 10.3 in a staging area (anyone who does a live upgrade
>> without testing is definitely on the FAR edge of the bell curve)
>> - 10.3 doesn't start up.  WTF?
>> - I read the error log.  It explains why it didn't start up, what the
>> risk is, and what you can do about it (explicitly turn off
>> authentication or enable authentication)
>>
>> The user then has the choice.  If his applications just don't do any
>> authentication and it's a big change to modify the apps, then I can
>> explicitly turn off authentication using
>> derby.connection.requireAuthentication = false.  But now I am aware of
>> my risk.  I can make plans to enable authentication in my apps and get
>> on the security bandwagon.
> I can see that many applications would fit this profile. I am worried, 
> however, about other applications which have been lulled into a laxer 
> process by Cloudscape/Derby's long track record of painless upgrades.
>>
>> At least we (the Derby team) won't silently let users expose
>> themselves -- we've given them their warning and now they are on their
>> own.
>>
>> So, my 2 cents: go with number 2.  A gentle slap in the face, and they
>> can make their choice.  One caveat: the error message needs to be
>> *very* clear with *why* we did this (describe the exposure) and *what*
>> the user can do about it (explicitly enable or disable
>> authentication).
>>
>> David
> I continue to be inclined to go with (3). The original issue 
> (DERBY-2196) was a request to install a security manager if the user 
> forgot to. I still think that's a good idea by itself. The follow-on 
> request was to stop giving the user a false sense of security. I think 
> that's a broader issue, some of whose details are mentioned by 
> DERBY-1056. Given the strong reaction to this email thread, our 
> inability to measure the residual exposure, and the lateness in the day, 
> I think that we should separate the two issues.
> 
> I volunteer to do (3).

With 3) can we restrict the file permissions in the default policy file. 
Currently it is:

permission java.io.FilePermission "${derby.system.home}${/}-", 
"read,write,delete";
permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";

The <<ALL FILES>> is dangerous if the server is running without 
authentication and listening to remote clients (as 3) allows).
(Just imagine if the server is started as super-user!)

How about just

permission java.io.FilePermission "${derby.system.home}${/}-", 
"read,write,delete";
permission java.io.FilePermission "${java.io.tmpdir}${/}-", 
"read,write,delete";

This would at least limit access to the derby.system.home and temp dirs.

Note that if derby.system.home is not set the network server sets it to 
user.dir.

Dan.

Mime
View raw message