From derby-user-return-13893-apmail-db-derby-user-archive=db.apache.org@db.apache.org Fri Sep 2 21:38:06 2011 Return-Path: X-Original-To: apmail-db-derby-user-archive@www.apache.org Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BE4E6785C for ; Fri, 2 Sep 2011 21:38:06 +0000 (UTC) Received: (qmail 13903 invoked by uid 500); 2 Sep 2011 21:38:06 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 13855 invoked by uid 500); 2 Sep 2011 21:38:05 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 13848 invoked by uid 99); 2 Sep 2011 21:38:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 21:38:05 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FRT_BEFORE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of roy.minet@comcast.net designates 76.96.62.40 as permitted sender) Received: from [76.96.62.40] (HELO qmta04.westchester.pa.mail.comcast.net) (76.96.62.40) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 21:37:58 +0000 Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id TvSj1h0051ei1Bg54xdefs; Fri, 02 Sep 2011 21:37:38 +0000 Received: from sz0138.wc.mail.comcast.net ([76.96.58.202]) by omta24.westchester.pa.mail.comcast.net with comcast id Txde1h00a4MnWwC3kxdedX; Fri, 02 Sep 2011 21:37:38 +0000 Date: Fri, 2 Sep 2011 21:37:37 +0000 (UTC) From: Roy.Minet@comcast.net To: Derby Discussion Message-ID: <1214250206.834872.1314999457902.JavaMail.root@sz0138a.westchester.pa.mail.comcast.net> In-Reply-To: <4E611302.30800@oracle.com> Subject: Re: Opinions on new security feature requested MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_834871_383690093.1314999457901" X-Originating-IP: [174.54.64.45] X-Mailer: Zimbra 6.0.10_GA_2709 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2697) ------=_Part_834871_383690093.1314999457901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Unless it is completely unavoidable, it should be possible to install=C2=A0= a later version AND NOT BREAK AN EXISTING APPLICATION.=C2=A0 To do so is ru= de and can be very disruptive.=20 ----- Original Message ----- From: "Dag H. Wanvik" =20 To: "Derby Discussion" =20 Sent: Friday, September 2, 2011 1:31:46 PM=20 Subject: Opinions on new security feature requested=20 Hi folks,=20 we are always working to make Derby more secure; in this day and age,=20 security is ever more on people's minds for obvious reasons;=20 IT systems are everywhere and the bad guys never tire of finding new=20 holes to break them. Up till now, Derby creates database files and logs=20 using the default operating system permission in effect. On Unix/linux=20 this is controlled by the umask of the process starting the Derby=20 engine, be in embedded or a standalone Derby network server. Similarly=20 on Windows, NTFS has a security model can be configured to give various=20 default permissions.=20 Now, often the defaults will allow other (than the one starting the VM)=20 OS users the permissions to read and possibly write to the database=20 files. This can be intention to allow several users to boot the same=20 (shared) database), or it can be accidental. In DERBY-5363 we have been=20 discussion use cases and scenarios for when it would be desirable to let=20 Derby be more secure than the default permissions. Other database also=20 do this, e.g. PostGreSQL, MS SQL server.=20 Typically, only the OS user creating the database would have access=20 (default behavior) unless one told the database to be lax and not worry=20 about tightening up the default OS permissions.=20 Obviously, one can achieve the same restrictive permissions, by setting=20 the umask to 0077 on Unix, or tweak the NTFS settings similarly=20 (Windows), but this requires some care and presumes that the users=20 remembers to do so (many people don't grok the NTFS security model..)=20 To be clear, one would be able to enable/disable this extra security by=20 providing Derby with a property setting, so the question is really what=20 is the msot appropriate default: use lax permissions (rely on the user=20 having tightened up be fore starting the VM), or use the new proactive=20 secure settings proposed in DERBY-5363.=20 Secure default pros:=20 - users will get better security by default. If one needs to share the=20 database files, one can use a property to get old, lax behavior.=20 - no need to change startup scripts to get better security=20 Secure default cons:=20 - upwards compatibility: if an installation relies on sharing database=20 files, on would have to start using a property after upgrading.=20 - requires at least Java 6 (on Unix), Java 7 on Windows/NTFS to work (an=20 incentive to upgrade, though :-)=20 In the discussion it as been suggested that many deployments, especially=20 of embedded Derby, rely on several OS users having permissions, so=20 changing the default Derby behavior would cause upgrade issues. Probably=20 for most client/server deployments, where the server is started from the=20 command line, it would be the same OS user starting the Derby server=20 every time. In mixed deployments (embedded, but the server is sometimes=20 started via the API), the latter may not hold true.=20 A possible trade-off between the concerns would thus be to start=20 embedded with the exisiting, lax permissions by default, but start the=20 server from the command line with a secure (restrictive) default. In=20 both cases, one would get the opposite behavior by providing a system=20 property on VM startup.=20 Before we settle the discussion on this, it would be good to hear what=20 you think! Thanks!=20 Dag=20 ------=_Part_834871_383690093.1314999457901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>Unless it= is completely unavoidable, it should be possible to install a later v= ersion AND NOT BREAK AN EXISTING APPLICATION.  To do so is rude and ca= n be very disruptive.


From: "Dag H. Wanvik" <dag.wanvik@oracle.com>
To: "D= erby Discussion" <derby-user@db.apache.org>
Sent: Friday, S= eptember 2, 2011 1:31:46 PM
Subject: Opinions on new security fea= ture requested

Hi folks,

we are always working to make Derby = more secure; in this day and age,
security is ever more on people's min= ds 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 da= tabase files and logs
using the default operating system permission in = effect. On Unix/linux
this is controlled by the umask of the process st= arting the Derby
engine, be in embedded or a standalone Derby network s= erver. Similarly
on Windows, NTFS has a security model can be configure= d to give various
default permissions.

Now, often the defaults w= ill allow other (than the one starting the VM)
OS users the permissions= to read and possibly write to the database
files. This can be intentio= n 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 sce= narios 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 wou= ld have access
(default behavior) unless one told the database to be la= x and not worry
about tightening up the default OS permissions.
Obvi= ously, 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 d= o 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 D= erby with a property setting, so the question is really what
is the mso= t appropriate default: use lax permissions (rely on the user
having tig= htened up be fore starting the VM), or use the new proactive
secure set= tings proposed in DERBY-5363.

Secure default pros:
- users will g= et 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 s= tartup scripts to get better security

Secure default cons:
- upwa= rds 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 man= y deployments, especially
of embedded Derby, rely on several OS users h= aving permissions, so
changing the default Derby behavior would cause u= pgrade issues. Probably
for most client/server deployments, where the s= erver is started from the
command line, it would be the same OS user st= arting 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 sta= rt
embedded with the exisiting, lax permissions by default, but start t= he
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

------=_Part_834871_383690093.1314999457901--