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 Wed, 30 May 2007 22:46:07 GMT
Daniel John Debrunner 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.
DERBY-1056 calls for printing the warning on the console as well as the 
log file. That might provide some incremental benefit. However, it's not 
likely to be useful for customers who startup Derby in a background 
process or as a service at boot time. Another issue I have with warnings 
is that, once they proliferate, they become a thicket of noise which 
obscures real signal.
> 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.
I think this would whittle down the incompatibility. It would provide a 
useful sanity check for applications which run on unprotected networks. 
It still might be too restrictive for apps which trust their users and 
run behind a firewall.

I don't know how to measure the residual exposure here. I have not had 
much success trawling derby-user for advice.
> 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.
The motivation for flunking the boot was to avoid giving the customer a 
false sense of security. This was briefly touched on in comments 
attached to DERBY-2206 (January 26, 2007, 8:05 am and 9:20 am). Maybe we 
were seeing the glass as half empty and should, instead, be happy that 
the glass is half full.
> 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.

4) Boot an unauthenticated server and install a security manager 
regardless of whether we're listening on localhost. Here the glass is 
half full and we remove the incompatibility.


View raw message