db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject secure-by-default definition attempt - WAS Re: broken network startup scripts
Date Fri, 09 Mar 2007 17:54:02 GMT
Rick Hillegas wrote:
> Daniel John Debrunner wrote:

>> 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.

I was thinking of a definition that was more along the lines of what 
actions are being prevented than some abstract definitions of secure.

So here's my take:

Secure-by-default prevents security attacks from a remote machine.

Assumptions are:
   operating system is secure
   java virtual machine is secure
   network is secure (ie. intranet)

Concern is only security attacks that are a direct result of the fact a 
Derby network server and databases are running on the server machine.

Restrictions applicable to all remote code:

    - must not be able to access any non-database information about the 
machine. (e.g. /etc/password)
    - must not be able to execute arbitrary code on the server machine

Restrictions applicable to remote code not associated a with an 
authenticated user:

  - must not be able to access any database information
  - must not be able to cause denial-of-service attacks for databases 
and the server (i.e. bring the server or a database down)

Restrictions applicable to remote code associated a with an 
authenticated user:

  - database activity must be limited to the permissions granted to the 
user (e.g. only shutdown a database if allowed, install a jar file etc.)

Some explicit non-goals:

  - denial of service attacks due to server cpu consumption by remote 
code is not addressed (e.g. frequent pings of the server, login attempts 
etc.)
  - denial of server by authenticated users due to significant disk or 
cpu usage is not addressed.

How's that as a starting point?
Dan.



Mime
View raw message