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 Wed, 30 May 2007 22:44:17 GMT
Hi, Dan, thanks for your response.  I appreciate you covering the
possible risks involved in each choice.  It would be great if your
description could be copied almost verbatim into the docs around this

I like 2 and 3 together, this seems the most secure without breaking

I also think that what you're saying is that if you are running a
network server without authentication you really are exposing yourself
and it shouldn't be done, and I think you've made your points well.
All the other databases NetBeans supports seem to require real
authentication, and actually the UI for NetBeans assumes
authentication is required even if it isn't used for Derby (the UI
always prompts for a user and password).

I guess the problem is that we (the Derby team) first delivered the
Network Server allowing authentication to be turned off, and perhaps
we should never have done this.  Embedded I understand, but the
Network Server with no authentication is a real risk.

I am going to log a bug in NB to enable authentication when running
the network server, and check with folks here to see if there are any
issues with that.  Since we're running the network server as a
different process, it shouldn't impact any NB code trying to do file
I/O and such.
Then we wouldn't get bitten by this when a user upgrades to 10.3.


On 5/30/07, Daniel John Debrunner <djd@apache.org> wrote:
> David Van Couvering wrote:
> > Also, if I understand things correctly, then when you upgrade to Derby
> > 10.3 the *default* behavior is that the Network Server will *not*
> > start up, because most users (in development anyway, which is where
> > people will first experience Derby 10.3) will not have turned on user
> > authentication.  I know it's turned off for NetBeans.
> >
> > it seems to me that if the user has not enabled user authentication,
> > they should be able to run the Network Server without the security
> > manager.  I can see two major usage modes:
> >
> > -> authentication turned on and security manager enabled
> > -> authentication turned off and security manager disabled
> >
> > It seems to me we should support the first scenario.  If the user has
> > authentication turned off, we can let the server start up with the
> > following message:  "WARNING: user authentication is not enabled.
> > You are now running in an insecure mode." And then turn off the
> > security manager for the network server.
> How about a minor re-wording ...
> "WARNING: user authentication is not enabled. You are now running in an
> insecure mode, your machine may have already been hacked by the time you
> read this."
> :-)
> > This keeps things compatible but lets users know they're not in a
> > secure mode.  If you keep seeing this in your server log every time
> > you start up, you'll get the hint.
> I'm not actually sure that people look in the log files on a regular
> basis, so I don't think relying on a warning to make a system secure is
> a good approach.
> However, I do wonder if the stopping boot with no-authentication is too
> severe. I see a couple of possible approaches (maybe three):
> 1) Block the boot only if the server is accepting remote clients
> (listening on something other than localhost). This then would "match"
> the comment in the 10.2 documentation under "derby.drda.host":
>    "Ensure that you are running under the security manager and that user
> authorization is enabled before you enable remote connections with this
> property."
>   Thus 10.3 is enforcing that "Ensure".
> This means the netbeans example would boot, that is any non-configured
> network server would boot. It would be open to connections and therefore
> hostile attacks from any user on that machine. A less of a risk, but
> still, by booting the (unauthenticated) network server on a shared
> machine one would be exposing oneself to having any other user have
> access to your own private files.
> 2) Boot an unauthenticated network server but install a security manager.
>    Allows at least DoS attacks (e.g. create many databases) from anyone
> who can connect. Limits their ability to perform execute arbitrary java
> code on the server's machine, but still may provide access to files
> owned by the user that started the network server.
> 3) Do 1) and 2)
>     Allow a boot of an unauthenticated server only listening on
> localhost and install a security manager. Potentially reduces the harm a
> user on the same machine could do.
> Dan.

View raw message