db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: SecurityManager incompatibility (was Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade)
Date Fri, 01 Jun 2007 19:03:04 GMT
Daniel John Debrunner wrote:
> 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!)
Hi Dan,

I agree that this is a dangerous permission. According to the comment on 
this permission, it is phrased broadly so that we don't break customer 
scripts which import/export tables, backup/restore databases, and load 
jar files.
> 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.
This will work for existing customers who 
import/export/backup/restore/loadJars to and from these directory trees. 
I am worried, in particular, that customers may not typically 
backup/restore to/from these directories. I think we would be 
introducing a significant incompatibility.

The comment on the permission urges the customer to fine-tune this 
dangerous permission. The user manuals also make this point. I think we 
need to underscore this issue in a release note.

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

View raw message