db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <dag.wan...@oracle.com>
Subject Opinions on new security feature requested
Date Fri, 02 Sep 2011 17:31:46 GMT
Hi folks,

we are always working to make Derby more secure; in this day and age, 
security is ever more on people's minds for obvious reasons;
IT systems are everywhere and the bad guys never tire of finding new 
holes to break them. Up till now, Derby creates database files and logs 
using the default operating system permission in effect. On Unix/linux 
this is controlled by the umask of the process starting the Derby 
engine, be in embedded or a standalone Derby network server. Similarly 
on Windows, NTFS has a security model can be configured to give various 
default permissions.

Now, often the defaults will allow other (than the one starting the VM) 
OS users the permissions to read and possibly write to the database 
files. This can be intention to allow several users to boot the same 
(shared) database), or it can be accidental. In DERBY-5363 we have been 
discussion use cases and scenarios for when it would be desirable to let 
Derby be more secure than the default permissions. Other database also 
do this, e.g. PostGreSQL, MS SQL server.

Typically, only the OS user creating the database would have access 
(default behavior) unless one told the database to be lax and not worry 
about tightening up the default OS permissions.
Obviously, one can achieve the same restrictive permissions, by setting 
the umask to 0077 on Unix, or tweak the NTFS settings similarly 
(Windows), but this requires some care and presumes that the users 
remembers to do so (many people don't grok the NTFS security model..)

To be clear, one would be able to enable/disable this extra security by 
providing Derby with a property setting, so the question is really what 
is the msot appropriate default: use lax permissions (rely on the user 
having tightened up be fore starting the VM), or use the new proactive 
secure settings proposed in DERBY-5363.

Secure default pros:
- users will get better security by default. If one needs to share the 
database files, one can use a property to get old, lax behavior.
- no need to change startup scripts to get better security

Secure default cons:
- upwards compatibility: if an installation relies on sharing database 
files, on would have to start using a property after upgrading.
- requires at least Java 6 (on Unix), Java 7 on Windows/NTFS to work (an 
incentive to upgrade, though :-)

In the discussion it as been suggested that many deployments, especially 
of embedded Derby, rely on several OS users having permissions, so 
changing the default Derby behavior would cause upgrade issues. Probably 
for most client/server deployments, where the server is started from the 
command line, it would be the same OS user starting the Derby server 
every time. In mixed deployments (embedded, but the server is sometimes 
started via the API), the latter may not hold true.

A possible trade-off between the concerns would thus be to start 
embedded with the exisiting, lax permissions by default, but start the 
server from the command line with a secure (restrictive) default. In 
both cases, one would get the opposite behavior by providing a system 
property on VM startup.

Before we settle the discussion on this, it would be good to hear what 
you think! Thanks!

Dag


Mime
View raw message