David Van Couvering wrote:
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.
Thanks, David. I've adopted your better name for this kind of policy.
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?
I did consider this option. I've updated the wiki page to record my
reasons for preferring the other approach: The default policy file
depends, I think, on other command line options. A "print-policy"
command would have to model all of the complexity of the "start" and
"shutdown" commands anyway, so, to my eyes, it looks like a
qualification of those commands rather than a separate command in its
own right.
Thanks,
-Rick
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.
