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.
And
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.
Regards,
-Rick
