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: secure-by-default definition attempt - WAS Re: broken network startup scripts
Date Mon, 19 Mar 2007 18:18:53 GMT
This pushes the discussion forward. It occurs to me that we need both a
positive statement of what we think we're protecting and a negative
statement of known security holes:

1) Limiting exposure: We intend to limit the kinds of security breaches
introduced by running Derby on a server machine.

2) Transparency: We intend to describe all of the security breaches
introduced by Derby which we know about. This will help customers
reason about other security mechanisms which they may need to add to
their operating systems and networks.

Dan said:

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


1) Secure-by-default limits the exposure to security attacks from a remote machine.

2) Here are the known security attacks which remote machines can still
launch using Derby: ...

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

Being concrete here will be very helpful. For instance:

o We should state whether we're assuming that intranet traffic is encrypted.

I don't understand what we're saying about the VM here. This wording suggests to me
that we assume the customer has brought the VM up under a security manager. But
that is the non-assumption which led to DERBY-2196 and this whole thread.

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

1) We do not know of any exposure to the threats listed above.

>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
>  - denial of server by authenticated users due to significant disk or
>cpu usage is not addressed.

I think that calling out the non-goals is very useful.

2) We do know that Derby enables these kinds of attacks. We're telling you
about these breaches so that you can close them via other mechanisms.

>How's that as a starting point?

View raw message