db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2109) System privileges
Date Mon, 08 Jan 2007 14:56:40 GMT
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,
> 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.

View raw message