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.
