db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering" <da...@vancouvering.com>
Subject Re: SecurityManager incompatibility (was Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade)
Date Sat, 02 Jun 2007 05:23:40 GMT
I agree, changing the default policy file as Dan suggests does not
seem to be backward compatible.

I believe it would be worthwhile to publicize the decision to go with
(3) and the reasons why to the derby-user list.  At least way we have
given our users a *chance* to say something one way or the other.

I may also do a quick blog about this and I can see what the feedback
there is like.

Thanks for listening!

David

On 6/1/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> 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.
>
> Thanks,
> -Rick
> >
> > Note that if derby.system.home is not set the network server sets it
> > to user.dir.
> >
> > Dan.
>
>

Mime
View raw message