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: broken network startup scripts
Date Thu, 01 Mar 2007 20:42:29 GMT
This thread has generated a lot of thought-provoking discussion. 
However, it has not discovered a solution that works for everyone. My 
instincts then are to leave the code alone:

o Starting with the next feature release, the network startup scripts 
are templates, not scripts which work out-of-the-box.

o The Release Notes will have to state this plainly and forcefully.

o The user guides will have to explain how to customize these templates.

Thanks to everyone who has participated in this discussion. Your 
feedback has helped me sort out my thoughts.

Regards,
-Rick


Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Andrew McIntyre wrote:
>>> On 2/27/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>>>>
>>>> Thanks for the quick response, Andrew. If we go with (4), then we have
>>>> to change our attitude about the startup scripts. Right now they work
>>>> out-of-the-box. With approach (4), they no longer work out-of-the-box.
>>>> Instead, they are templates which have to be customized.
>>>
>>> Is adding an argument to the invocation of a script customizing a
>>> template? The script itself need not be edited to start up the server.
>>> Also, as of the moment, I believe this only affects the
>>> startNetworkServer scripts, or did I miss something?
>>>
>>>> It would be nice to tell customers how to do this. What do you think:
>>>> should we document this:
>>>>
>>>> a) in comments in the scripts themselves
>>>> b) in the Admin Guide
>>>> c) in the Getting Started Guide
>>>> d) all of the above
>>>> e) something else
>>>
>>> Since I've had some time to think about it a little more, I'd vote for
>>> (e): (d) and make the script(s) smarter. e.g. if no arguments were
>>> given to the script and the startNetworkServer initially fails to
>>> start the network server, detect the exit code of 1, print a LOUD
>>> warning, and start the server up with the -noSecurityManager flag.
>>> Still starts the network server up with the behavior of the previous
>>> release, and warns them that the server they just started up is
>>> insecure. What do you think?
>>
>> I think just allowing the script to accept the -noSecurityManager 
>> flag is enough. Booting with no security when the user was expecting 
>> security seems like a huge problem to me. There's a very good chance 
>> that the startup is automated and no-one notices the server is being 
>> booted without security.
>>
>> I think some of this goes back to no good definition of what 
>> "secure-by-default" means. Without a good definition it's hard to 
>> make a decision as to if a behaviour is achieving the desired goal.
> If someone wants to offer a definition, I'm eager to consider it. Here 
> are some related terms:
>
> MaximallySecure: You might get close to this term by turning on every 
> security feature which Derby supports: Java Security, authentication, 
> authorization, encryption. Then again, maybe your policy file could be 
> tightened up. Maybe your authentication scheme could be improved. 
> Maybe you are running Derby in an environment which is unsecure for 
> reasons which Derby doesn't understand. MaximallySecure could be a 
> fleeting state of mind.
>
> MinimallySecure: You might get close to this term by turning off every 
> security feature which Derby supports. Then again, by loading in some 
> dangerous user-defined procedures, you could make the situation 
> arbitrarily worse. Is MinimallySecure just a state of mind too?
>
> SecureEnough: This could fall anywhere on the continuum between 
> MaximallySecure and MinimallySecure. SecureEnough slides around 
> depending on the application.
>
> TooSecure: Slides around somewhere else on the continuum. Java 
> Security and encryption impose runtime costs, which some customers may 
> not tolerate.
>
> Unsecure: Slides around between MinimallySecure and SecureEnough.
>
> secure-by-default: Right now, to me this looks like a factory-shipped 
> approximation of SecureEnough. The customer may appreciate this as 
> TooSecure or Unsecure.
>
> We started down this path by deciding that MinimallySecure wasn't 
> SecureEnough. Later on, we decided not to require SQL authorization. So
>
>   MaximallySecure >=
>   TooSecure >
>   secure-by-default >
>   Unsecure >=
>   MinimallySecure
>
> I don't know how to characterize the security we're proposing for the 
> 10.3 server:
>
> ON: Java Security, authentication
>
> OFF: authorization, disk encryption, wire encryption
>
> MAYBE: username/password encryption
>
> I'm not sure I can state what our model is.
>
> Regards,
> -Rick
>
>>
>> The original discussion has this phrase:
>>
>> "... system/database owners are trusting the database system to 
>> ensure that their system cannot be attacked."
>>
>> For example I was thinking that maybe if the server was only 
>> listening on localhost/127.0.0.1 then there's no need to install a 
>> security manager. But how does that fit into various people's concept 
>> of secure by default.
>>
>> Dan.
>>
>>
>


Mime
View raw message