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 Mon, 04 Jun 2007 16:57:47 GMT
I think it would be nice to present all the options, with the
consequences of each choice, and ask for a vote.  None of them are
perfect, but it would be good to get a sense of where most of our
users are headed.

If I understand the options they should be classified across
"authentication enabled" and "authentication disabled/not specified"

Under authentication enabled, the choices are:

- Automatically install a security manager
Consequences: reduces risk of destructive use of Java code,
potentially reduced performance, possible that some application code
will no longer run until permissions are granted

- Do not install a security manager
Consequences: increased risk of maleficent Java code execution

Our recommended course of action: install a security manager unless
explicitly told not to with -noSecurityManager

Under authentication disabled:

- Automatically install  a security manager
Consequences: reduces risk of destructive use of Java code,
potentially reduced performance, possible that some application code
will no longer run until permissions are granted

- Do not install a security manager
Consequences: increased risk of maleficent Java code execution

- Prevent boot if authentication is disabled
Consequences: ensures a secure application environment, requires user
to "opt in" to a less secure environment.  Will break applications
where configuration of Derby is not an option or is not possible (e.g.
NetBeans starting network server from within its own Java source
base).

Our recommended course of action: always install a security manager,
and require authentication be enabled if the server is accepting
connections outside of the local host.

Something like that...

Thanks!

David
On 6/4/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> Hi David,
>
> Thanks for helping me puzzle through these issues. I'm not clear on what
> question should be posed to derby-user. Here are some possibilities:
>
> 1) Should we install a security manager if the user neglects to? Or are
> we still introducing intolerable incompatibilities: a) potential runtime
> performance drag, b) possibility that user functions and procedures may
> not run until they are granted sufficient privileges.
>
> 2) Should we not bother to install a security manager if authentication
> is turned off?
>
> 3) Should the server fail to boot if Derby believes it has not been
> configured safely?
>
> 4) Something else?
>
> Thanks,
> -Rick
>
> David Van Couvering wrote:
> > 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