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.
Right: 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 etc.) - 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? Dan.
