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 Wed, 30 May 2007 21:39:59 GMT
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.





Mime
View raw message