Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Mon, 04 Jun 2007 07:02:35 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: SecurityManager incompatibility (was Re: 10.3 Concern: Need to
 make DBO restrictions [Derby-2264] optional at upgrade)
In-reply-to: <56a83cd00706012223n673515dcs2d2d507f96a70f21@mail.gmail.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <46641B7B.7040505@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <56a83cd00705301401y303fd811mef651f672d3d3d34@mail.gmail.com>
 <465EF01F.9060201@sun.com> <465EF930.5020808@apache.org>
 <56a83cd00705311147m5b80e03br41ab19622d4cc341@mail.gmail.com>
 <466060DF.80006@sun.com> <46606871.3080002@apache.org>
 <46606D68.7080101@sun.com>
 <56a83cd00706012223n673515dcs2d2d507f96a70f21@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060828)

Hi David,

Thanks for helping me puzzle through these issues. I'm not clear on what 
question should be posed to derby-user. Here are some possibilities:

1) Should we install a security manager if the user neglects to? Or are 
we still introducing intolerable incompatibilities: a) potential runtime 
performance drag, b) possibility that user functions and procedures may 
not run until they are granted sufficient privileges.

2) Should we not bother to install a security manager if authentication 
is turned off?

3) Should the server fail to boot if Derby believes it has not been 
configured safely?

4) Something else?

Thanks,
-Rick

David Van Couvering wrote:
> I agree, changing the default policy file as Dan suggests does not
> seem to be backward compatible.
>
> I believe it would be worthwhile to publicize the decision to go with
> (3) and the reasons why to the derby-user list.  At least way we have
> given our users a *chance* to say something one way or the other.
>
> I may also do a quick blog about this and I can see what the feedback
> there is like.
>
> Thanks for listening!
>
> David
>
> On 6/1/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>> Daniel John Debrunner wrote:
>> > Rick Hillegas wrote:
>> >> Thanks to Dan and David for your advice. Some more musings follow:
>> >>
>> >> David Van Couvering wrote:
>> >>> I am also torn between 2 and 3 but am leaning towards 2, 
>> especially if
>> >>> we document this is what we should do.
>> >>>
>> >>> Does Derby 10.3 have a beta period?  If we can get a strong 
>> amount of
>> >>> users testing Derby 10.3 in beta we might get some good feedback 
>> if we
>> >>> go with option 2.  If we start with 3 from the get-go,  nobody would
>> >>> give us feedback (as it continues to work the way it did in 
>> 10.2), but
>> >>> we could be complicit in letting users expose themselves in a
>> >>> dangerous way.
>> >> Our release process doesn't factor in what I would call a beta test.
>> >> To my way of thinking, a real beta program would require a lot of
>> >> preparation, which we haven't done, and a lot of monitoring, which we
>> >> haven't planned.
>> >>
>> >> In short, I don't think our release process will give you the
>> >> feedback you want here. Possibly we would get quick, negative
>> >> feedback that (2) is the wrong approach. But I don't think we'll get
>> >> sufficient feedback to feel confident that (2) is the right approach.
>> >>>
>> >>> Like I said, if you're making your DB available on machines other 
>> than
>> >>> localhost, you are running in a non-development mode.  I imagine the
>> >>> following scenario where I am your standard IT guy eating donuts in
>> >>> the server room:
>> >>>
>> >>> - I upgrade to 10.3 in a staging area (anyone who does a live 
>> upgrade
>> >>> without testing is definitely on the FAR edge of the bell curve)
>> >>> - 10.3 doesn't start up.  WTF?
>> >>> - I read the error log.  It explains why it didn't start up, what 
>> the
>> >>> risk is, and what you can do about it (explicitly turn off
>> >>> authentication or enable authentication)
>> >>>
>> >>> The user then has the choice.  If his applications just don't do any
>> >>> authentication and it's a big change to modify the apps, then I can
>> >>> explicitly turn off authentication using
>> >>> derby.connection.requireAuthentication = false.  But now I am 
>> aware of
>> >>> my risk.  I can make plans to enable authentication in my apps 
>> and get
>> >>> on the security bandwagon.
>> >> I can see that many applications would fit this profile. I am
>> >> worried, however, about other applications which have been lulled
>> >> into a laxer process by Cloudscape/Derby's long track record of
>> >> painless upgrades.
>> >>>
>> >>> At least we (the Derby team) won't silently let users expose
>> >>> themselves -- we've given them their warning and now they are on 
>> their
>> >>> own.
>> >>>
>> >>> So, my 2 cents: go with number 2.  A gentle slap in the face, and 
>> they
>> >>> can make their choice.  One caveat: the error message needs to be
>> >>> *very* clear with *why* we did this (describe the exposure) and 
>> *what*
>> >>> the user can do about it (explicitly enable or disable
>> >>> authentication).
>> >>>
>> >>> David
>> >> I continue to be inclined to go with (3). The original issue
>> >> (DERBY-2196) was a request to install a security manager if the user
>> >> forgot to. I still think that's a good idea by itself. The follow-on
>> >> request was to stop giving the user a false sense of security. I
>> >> think that's a broader issue, some of whose details are mentioned by
>> >> DERBY-1056. Given the strong reaction to this email thread, our
>> >> inability to measure the residual exposure, and the lateness in the
>> >> day, I think that we should separate the two issues.
>> >>
>> >> I volunteer to do (3).
>> >
>> > With 3) can we restrict the file permissions in the default policy
>> > file. Currently it is:
>> >
>> > permission java.io.FilePermission "${derby.system.home}${/}-",
>> > "read,write,delete";
>> > permission java.io.FilePermission "<<ALL FILES>>", 
>> "read,write,delete";
>> >
>> > The <<ALL FILES>> is dangerous if the server is running without
>> > authentication and listening to remote clients (as 3) allows).
>> > (Just imagine if the server is started as super-user!)
>> Hi Dan,
>>
>> I agree that this is a dangerous permission. According to the comment on
>> this permission, it is phrased broadly so that we don't break customer
>> scripts which import/export tables, backup/restore databases, and load
>> jar files.
>> >
>> > How about just
>> >
>> > permission java.io.FilePermission "${derby.system.home}${/}-",
>> > "read,write,delete";
>> > permission java.io.FilePermission "${java.io.tmpdir}${/}-",
>> > "read,write,delete";
>> >
>> > This would at least limit access to the derby.system.home and temp 
>> dirs.
>> This will work for existing customers who
>> import/export/backup/restore/loadJars to and from these directory trees.
>> I am worried, in particular, that customers may not typically
>> backup/restore to/from these directories. I think we would be
>> introducing a significant incompatibility.
>>
>> The comment on the permission urges the customer to fine-tune this
>> dangerous permission. The user manuals also make this point. I think we
>> need to underscore this issue in a release note.
>>
>> Thanks,
>> -Rick
>> >
>> > Note that if derby.system.home is not set the network server sets it
>> > to user.dir.
>> >
>> > Dan.
>>
>>