db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-2109) System privileges
Date Fri, 15 Dec 2006 19:58:31 GMT
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).


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 
SL2 - expect security out of the box
SL3 - willing to manage security to allow qualified users to have more 

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.


View raw message