This looks very interesting and promising.
I would rename "Exposed" to "Open", or some other word to indicate that
security will be managed by a third party like an embedding app server.
I have to be honest I really hate the UI for Java security. The policy
file is so arcane. Does anyone know if there is a nice UI that runs on
top of a java security policy file that makes it easier to manage it?
I like the idea of spitting out the policy file, but it doesn't seem
right to me that it would be part of an existing command. Why not just
create a new command called "print-policy" or something like that
instead of overloading the existing "stop" and "shutdown" utilities?
Thanks,
David
Rick Hillegas wrote:
I have taken a stab at describing various security expectations which
customers might have and also how we could balance these expectations
against the desire to run the network server "secure by default". The
following wiki page addresses these issues:
http://wiki.apache.org/db-derby/SecurityExpectations
Thanks in advance for your feedback,
-Rick
Daniel John Debrunner wrote:
Oystein Grovlen - Sun Norway wrote:
Rick Hillegas wrote:
> It seems to me a sysadmin needs our system privileges because she
wants
> to prevent malicious shutdown (shutdownEngine privilege) and resource
> hogging (createDatabase privilege). I suspect that she also wants to
> control malicious shutdown via unauthorized calls to System.exit()
and
> resource hogging via unauthorized use of java.io classes. For
instance,
> she needs to prevent the following:
A lot of systems will not have any externally installed java code, and
will not consider your case to be an issue. For many such systems,
the main concern is not malicious users, but things happening by
accident.
Or they are not concerned about malicious attacks until they actually
happen to their own server.
Maybe it's time to step back and lay out the bigger picture of what is
being attempted here. Seems there are a number of configurations and
levels of willingness for the system owner to handle security.
In all of these cases I'm just thinking about (as in DERBY-2109) the
potential actions a client could do if they can connect to the server
(either from a remote or the same host).
Configurations
--------------
standalone client server
CS1 - out of the box (localhost only)
CS2 - enabled for network access
embedded network server
EN1 - local host only
EN2 - enabled for network access
System owner Security level
---------------------------
SL1 - don't care (known to be on a secure network/limited use/just
don't care)
SL2 - expect security out of the box
SL3 - willing to manage security to allow qualified users to have more
rights
Maybe someone could drive defining expectations here on a wiki page.
For example, it seems with {CS1,CS2} & SL2 Derby should match the
security provided by typical client server systems such as DB2,
Oracle, etc. I think in this case system/database owners are trusting
the database system to ensure that their system cannot be attacked. So
maybe if Derby is booted as a standalone server with no security
manager involved, it should install one with a default security
policy. Thus allowing Derby to use Java security manager to manage
system privileges but not requiring everyone to become familiar with
them.
Dan.
