You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by "Dag H. Wanvik" <da...@oracle.com> on 2011/09/02 19:31:46 UTC
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
Posted by Peter Ondruška <pe...@kaibo.eu>.
+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 <da...@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
Posted by Ro...@comcast.net.
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" <da...@oracle.com>
To: "Derby Discussion" <de...@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