Opinions on new security feature requested
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
Re: Opinions on new security feature requested
+1 for more restrictive permissions. Actually when I run Derby on Unix it runs under own user+group and database files are not accessible by others. On Fri, Sep 2, 2011 at 7:31 PM, Dag H. Wanvik dag.wan...@oracle.com wrote: 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
Re: Opinions on new security feature requested
Unless it is completely unavoidable, it should be possible to install a later version AND NOT BREAK AN EXISTING APPLICATION. To do so is rude and can be very disruptive. - Original Message - From: Dag H. Wanvik dag.wan...@oracle.com To: Derby Discussion derby-user@db.apache.org Sent: Friday, September 2, 2011 1:31:46 PM Subject: Opinions on new security feature requested 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
