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 Rick Hillegas <ri...@oracle.com> on 2011/09/19 18:39:07 UTC
Derby secure by default
The Derby developers are considering introducing a single master
security property. Turning this property on will enable most Derby
security mechanisms:
1) Authentication - Will be on, requiring username/password credentials
at connection time. Derby will supply a default authentication mechanism.
2) SQL authorization - Will be on, hiding a user's data from other
people. In addition, Derby will support more SQL Standard protections
for Java routines.
3) File permissions - Will be tightened as described by DERBY-5363.
4) PUBLIC -This keyword will not be allowed as a user name.
5) SSL/TLS encryption - Will shield client/server traffic.
6) Server administration - Will require credentials.
When the property is off, Derby will behave as it does today:
Authentication, authorization, and network encryption will be off, file
permissions will inherit defaults from the account which runs the VM,
PUBLIC will be a legal user name, and server administration won't need
credentials.
This new master property will make it easier to configure a more secure
application. We want to introduce the property in an upcoming 10.x
release, where it will default to being off. That means that it won't
cause compatibility problems.
Later on, we might change the default for this property so that it would
normally be turned on. This would make Derby more secure out of the box
at the cost of breaking existing applications. Many applications would
need to explicitly turn the property off in order to run as they did
previously. Release notes would document this behavioral change and we
would bump the major release id from 10 to 11 in order to call attention
to the change.
We would like your feedback on this trade-off between security out of
the box versus disruption. Should this extra security be enabled by default?
Thanks,
-Rick
Re: Derby secure by default
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas wrote:
> I'm also concerned about the embedded database on a USB stick. I could
> argue that it is more vulnerable than the server-side database locked up
> in a machine room.
Derby has one answer to this issue and that is encrypted databases. I
don't think anything other than that is secure. Because if you lose
ownership of the files anyone can use a version of the open source
software to look at the data no matter what you do with authentication
or authorization. I sort of doubt even file permissions would help
if someone has physical control of the device and can mount it anywhere.
Having said that, I don't want to also enable encryption by default for
embedded derby. It is unnecessary for many applications and imposes
performance degredation and application complexity.
Historically Derby was never meant to be secure. It was designed to
be embedded and for owning applications to handle security. Early on
the issue of losing ownership of the files was considered and so
encrytion was added. Eventually client/server was added and even later
sql authorization, but it was not expected to be used in general for
embedded applications.
>> While many possibly get in the way for many zero-admin
>> embedded applications.
> I'm imagining that this change may be fairly unobtrusive. For an
> embedded database which has only one user (the dbo), the big change is
> that the dbo has to specify a username and password. There won't be any
> need to GRANT access to other users so (2) won't be noticed. Items (3)
> and (4) won't burden most applications. (5) and (6) are only issues for
> client/server usage.
In many cases I don't think this is true. I know users I work with
currently run an embedded derby application as a number of different
users and their current application does not use authentication or
authorization. As with other files used by the application they manage
access to db files as appropriate for their application.
>> Since we have one codeline for the most part
>> for both it is hard to have one default.
> I agree that a common default would be best. It will make it easier to
> reason about Derby's behavior and simplify our user guides.
>
> Thanks,
> -Rick
>>
>>
>> Rick Hillegas wrote:
>>> The Derby developers are considering introducing a single master
>>> security property. Turning this property on will enable most Derby
>>> security mechanisms:
>>>
>>> 1) Authentication - Will be on, requiring username/password
>>> credentials at connection time. Derby will supply a default
>>> authentication mechanism.
>>>
>>> 2) SQL authorization - Will be on, hiding a user's data from other
>>> people. In addition, Derby will support more SQL Standard protections
>>> for Java routines.
>>>
>>> 3) File permissions - Will be tightened as described by DERBY-5363.
>>>
>>> 4) PUBLIC -This keyword will not be allowed as a user name.
>>>
>>> 5) SSL/TLS encryption - Will shield client/server traffic.
>>>
>>> 6) Server administration - Will require credentials.
>>>
>>> When the property is off, Derby will behave as it does today:
>>> Authentication, authorization, and network encryption will be off,
>>> file permissions will inherit defaults from the account which runs
>>> the VM, PUBLIC will be a legal user name, and server administration
>>> won't need credentials.
>>>
>>> This new master property will make it easier to configure a more
>>> secure application. We want to introduce the property in an upcoming
>>> 10.x release, where it will default to being off. That means that it
>>> won't cause compatibility problems.
>>>
>>> Later on, we might change the default for this property so that it
>>> would normally be turned on. This would make Derby more secure out of
>>> the box at the cost of breaking existing applications. Many
>>> applications would need to explicitly turn the property off in order
>>> to run as they did previously. Release notes would document this
>>> behavioral change and we would bump the major release id from 10 to
>>> 11 in order to call attention to the change.
>>>
>>> We would like your feedback on this trade-off between security out of
>>> the box versus disruption. Should this extra security be enabled by
>>> default?
>>>
>>> Thanks,
>>> -Rick
>>>
>>>
>>
>>
>
>
Re: Derby secure by default
Posted by Rick Hillegas <ri...@oracle.com>.
On 9/20/11 8:41 AM, Mamta Satoor wrote:
> Hi Rick,
>
> Does this mean that a pre-existing database will always be run with
> the knob off after hard-upgrade to 11.x release(or whatever the
> release number which will have the security features)?
Hi Mamta,
I think that we will minimize upgrade problems if the knob defaults to
"false" for legacy databases. That means that those databases won't
enjoy the convenience of turning on (1-6) with one knob.
> Or will "B)
> Security level" give users the option to use security features after
> hard-upgrade?
I think that "derby.security.basic=false" (for option A) and
"derby.security.level=none" (for option B) simply mean that the database
follows the security behavior of the 10.x releases. Security features
can still be enabled and disabled as in 10.x--you just don't have a
master knob which turns them on.
Thanks,
-Rick
> thanks,
> Mamta
>
> On Tue, Sep 20, 2011 at 8:09 AM, Rick Hillegas<ri...@oracle.com> wrote:
>> On 9/19/11 5:28 PM, Kathey Marsden wrote:
>>> On 9/19/2011 1:20 PM, José Ventura wrote:
>>>> I'm not sure whether making the default value "on" will actually improve
>>>> security as a whole. If a developer hasn't given thought to security, there
>>>> are plenty of other pitfalls that may compromise an application (e.g. "where
>>>> should I store the (previously unneeded yet now required) username and
>>>> password?").
>>>>
>>>> On the other hand, if s/he did in fact think about security, then odds
>>>> are that are a simple, concise documentation will point him/her to happily
>>>> turn on the switch with minimum nuisance, and proceed to secure the rest of
>>>> the application.
>>>>
>>> I think this is a very good point. The claim of "secure by default" is a
>>> very strong claim and may give a false sense of overall security. Some
>>> things, like encryption and perhaps stricter security manager settings are
>>> not part of the default, but might be an important part of actually securing
>>> a particular application. I agree it is good for the application developer
>>> to plan security and for us to make it as easy as possible for them to do so
>>> from a Derby perspective.
>>>
>>> Perhaps the conversation of the default is premature. Perhaps we should
>>> first nail down the easy security knob and understand its behavior and
>>> usefulness and then discuss whether it should/could be the default.
>>> Kathey
>>>
>>>
>>>
>>>
>> Thanks, talking about these details would be useful now.
>>
>> A) On/off switch - A simple scheme would be a property with two values. The
>> property is stored in the database at creation time, as is done with
>> derby.connection.requireAuthentication. Once stored in the database, the
>> property can't be changed.
>>
>> derby.security.basic=true
>>
>> This enables the initial set of security features which I included in my
>> first posting (copied at the end of this message).
>>
>> derby.security.basic=false
>>
>> This is the default for a pre-existing database. If no value for the
>> property is stored in the database, that is identical to a stored value of
>> "derby.security.basic=false". This gives you the wide-open security behavior
>> of the 10.x series of releases: none of the security features are enabled by
>> default and you have to configure each security feature individually.
>>
>> This is what I had in mind. However, more flexible schemes are possible. I
>> haven't given these much thought. Options (B) and (C) below have the
>> advantage that machinery will be in place if we need to add higher security
>> levels later on.
>>
>> ----------------------------
>>
>> B) Security level - A more complicated scheme would be a property which
>> would allow you to dial the security level up and down. As with the on/off
>> switch, the property would be stored in the database at creation time. I
>> haven't thought about the implications of changing it afterward.
>>
>> derby.security.level=
>>
>> Can be set to one of the following:
>>
>> none This is the wide-open security behavior of the 10.x
>> series.
>> basic This enables the security features at the end of this
>> message.
>> encrypted This is basic plus encryption.
>>
>> If no value for the property is stored in the database, that is identical to
>> a stored value of "derby.security.level=none".
>>
>> C) Release level - A more complicated scheme would be a property which would
>> allow you to peg the security level to what was considered best practices
>> when a particular release was published. E.g.:
>>
>> derby.security.version=10.11.4.3
>>
>>
>> -----------------------------
>>
>> Here is the initial set of security features which would be enabled in 11.x
>> if the master knob were set:
>>
>> 1) Authentication - Will be on, requiring username/password credentials at
>> connection time. Derby will supply a default authentication mechanism.
>>
>> 2) SQL authorization - Will be on, hiding a user's data from other people.
>> In addition, Derby will support more SQL Standard protections for Java
>> routines.
>>
>> 3) File permissions - Will be tightened as described by DERBY-5363.
>>
>> 4) PUBLIC -This keyword will not be allowed as a user name.
>>
>> 5) SSL/TLS encryption - Will shield client/server traffic.
>>
>> 6) Server administration - Will require credentials.
>>
>>
Re: Derby secure by default
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Rick,
Does this mean that a pre-existing database will always be run with
the knob off after hard-upgrade to 11.x release(or whatever the
release number which will have the security features)? Or will "B)
Security level" give users the option to use security features after
hard-upgrade?
thanks,
Mamta
On Tue, Sep 20, 2011 at 8:09 AM, Rick Hillegas <ri...@oracle.com> wrote:
> On 9/19/11 5:28 PM, Kathey Marsden wrote:
>>
>> On 9/19/2011 1:20 PM, José Ventura wrote:
>>>
>>> I'm not sure whether making the default value "on" will actually improve
>>> security as a whole. If a developer hasn't given thought to security, there
>>> are plenty of other pitfalls that may compromise an application (e.g. "where
>>> should I store the (previously unneeded yet now required) username and
>>> password?").
>>>
>>> On the other hand, if s/he did in fact think about security, then odds
>>> are that are a simple, concise documentation will point him/her to happily
>>> turn on the switch with minimum nuisance, and proceed to secure the rest of
>>> the application.
>>>
>> I think this is a very good point. The claim of "secure by default" is a
>> very strong claim and may give a false sense of overall security. Some
>> things, like encryption and perhaps stricter security manager settings are
>> not part of the default, but might be an important part of actually securing
>> a particular application. I agree it is good for the application developer
>> to plan security and for us to make it as easy as possible for them to do so
>> from a Derby perspective.
>>
>> Perhaps the conversation of the default is premature. Perhaps we should
>> first nail down the easy security knob and understand its behavior and
>> usefulness and then discuss whether it should/could be the default.
>> Kathey
>>
>>
>>
>>
> Thanks, talking about these details would be useful now.
>
> A) On/off switch - A simple scheme would be a property with two values. The
> property is stored in the database at creation time, as is done with
> derby.connection.requireAuthentication. Once stored in the database, the
> property can't be changed.
>
> derby.security.basic=true
>
> This enables the initial set of security features which I included in my
> first posting (copied at the end of this message).
>
> derby.security.basic=false
>
> This is the default for a pre-existing database. If no value for the
> property is stored in the database, that is identical to a stored value of
> "derby.security.basic=false". This gives you the wide-open security behavior
> of the 10.x series of releases: none of the security features are enabled by
> default and you have to configure each security feature individually.
>
> This is what I had in mind. However, more flexible schemes are possible. I
> haven't given these much thought. Options (B) and (C) below have the
> advantage that machinery will be in place if we need to add higher security
> levels later on.
>
> ----------------------------
>
> B) Security level - A more complicated scheme would be a property which
> would allow you to dial the security level up and down. As with the on/off
> switch, the property would be stored in the database at creation time. I
> haven't thought about the implications of changing it afterward.
>
> derby.security.level=
>
> Can be set to one of the following:
>
> none This is the wide-open security behavior of the 10.x
> series.
> basic This enables the security features at the end of this
> message.
> encrypted This is basic plus encryption.
>
> If no value for the property is stored in the database, that is identical to
> a stored value of "derby.security.level=none".
>
> C) Release level - A more complicated scheme would be a property which would
> allow you to peg the security level to what was considered best practices
> when a particular release was published. E.g.:
>
> derby.security.version=10.11.4.3
>
>
> -----------------------------
>
> Here is the initial set of security features which would be enabled in 11.x
> if the master knob were set:
>
> 1) Authentication - Will be on, requiring username/password credentials at
> connection time. Derby will supply a default authentication mechanism.
>
> 2) SQL authorization - Will be on, hiding a user's data from other people.
> In addition, Derby will support more SQL Standard protections for Java
> routines.
>
> 3) File permissions - Will be tightened as described by DERBY-5363.
>
> 4) PUBLIC -This keyword will not be allowed as a user name.
>
> 5) SSL/TLS encryption - Will shield client/server traffic.
>
> 6) Server administration - Will require credentials.
>
>
Re: Derby secure by default
Posted by Rick Hillegas <ri...@oracle.com>.
On 9/19/11 5:28 PM, Kathey Marsden wrote:
> On 9/19/2011 1:20 PM, José Ventura wrote:
>>
>> I'm not sure whether making the default value "on" will actually
>> improve security as a whole. If a developer hasn't given thought to
>> security, there are plenty of other pitfalls that may compromise an
>> application (e.g. "where should I store the (previously unneeded yet
>> now required) username and password?").
>>
>> On the other hand, if s/he did in fact think about security, then
>> odds are that are a simple, concise documentation will point him/her
>> to happily turn on the switch with minimum nuisance, and proceed to
>> secure the rest of the application.
>>
> I think this is a very good point. The claim of "secure by default"
> is a very strong claim and may give a false sense of overall
> security. Some things, like encryption and perhaps stricter security
> manager settings are not part of the default, but might be an
> important part of actually securing a particular application. I agree
> it is good for the application developer to plan security and for us
> to make it as easy as possible for them to do so from a Derby
> perspective.
>
> Perhaps the conversation of the default is premature. Perhaps we
> should first nail down the easy security knob and understand its
> behavior and usefulness and then discuss whether it should/could be
> the default.
> Kathey
>
>
>
>
Thanks, talking about these details would be useful now.
A) On/off switch - A simple scheme would be a property with two values.
The property is stored in the database at creation time, as is done with
derby.connection.requireAuthentication. Once stored in the database, the
property can't be changed.
derby.security.basic=true
This enables the initial set of security features which I included in my
first posting (copied at the end of this message).
derby.security.basic=false
This is the default for a pre-existing database. If no value for the
property is stored in the database, that is identical to a stored value
of "derby.security.basic=false". This gives you the wide-open security
behavior of the 10.x series of releases: none of the security features
are enabled by default and you have to configure each security feature
individually.
This is what I had in mind. However, more flexible schemes are possible.
I haven't given these much thought. Options (B) and (C) below have the
advantage that machinery will be in place if we need to add higher
security levels later on.
----------------------------
B) Security level - A more complicated scheme would be a property which
would allow you to dial the security level up and down. As with the
on/off switch, the property would be stored in the database at creation
time. I haven't thought about the implications of changing it afterward.
derby.security.level=
Can be set to one of the following:
none This is the wide-open security behavior of the 10.x
series.
basic This enables the security features at the end of
this message.
encrypted This is basic plus encryption.
If no value for the property is stored in the database, that is
identical to a stored value of "derby.security.level=none".
C) Release level - A more complicated scheme would be a property which
would allow you to peg the security level to what was considered best
practices when a particular release was published. E.g.:
derby.security.version=10.11.4.3
-----------------------------
Here is the initial set of security features which would be enabled in
11.x if the master knob were set:
1) Authentication - Will be on, requiring username/password credentials
at connection time. Derby will supply a default authentication mechanism.
2) SQL authorization - Will be on, hiding a user's data from other
people. In addition, Derby will support more SQL Standard protections
for Java routines.
3) File permissions - Will be tightened as described by DERBY-5363.
4) PUBLIC -This keyword will not be allowed as a user name.
5) SSL/TLS encryption - Will shield client/server traffic.
6) Server administration - Will require credentials.
Re: Derby secure by default
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 9/19/2011 1:20 PM, José Ventura wrote:
>
> I'm not sure whether making the default value "on" will actually
> improve security as a whole. If a developer hasn't given thought to
> security, there are plenty of other pitfalls that may compromise an
> application (e.g. "where should I store the (previously unneeded yet
> now required) username and password?").
>
> On the other hand, if s/he did in fact think about security, then odds
> are that are a simple, concise documentation will point him/her to
> happily turn on the switch with minimum nuisance, and proceed to
> secure the rest of the application.
>
I think this is a very good point. The claim of "secure by default" is
a very strong claim and may give a false sense of overall security.
Some things, like encryption and perhaps stricter security manager
settings are not part of the default, but might be an important part of
actually securing a particular application. I agree it is good for the
application developer to plan security and for us to make it as easy as
possible for them to do so from a Derby perspective.
Perhaps the conversation of the default is premature. Perhaps we
should first nail down the easy security knob and understand its
behavior and usefulness and then discuss whether it should/could be the
default.
Kathey
Re: Derby secure by default
Posted by Matt Pouttu-Clarke <Ma...@icrossing.com>.
Embedded applications have to secure their own points of entry and turning
Derby security on by default will do nothing. Unless the Java security
manager is active, everything is wide open via the reflection APIs when you
are embedded in-process with the database.
Best-guess for me would be if the Java security manager is turned on then
enable default security for the database, whether you are in network server
mode or embedded mode. If people want to tolerate the overhead of security
manager calls in order to prevent malware in the JVM then they would also
most likely also be willing to tolerate the additional overhead of Derby
security by default.
Just a thought...
Cheers,
Matt
On 9/19/11 1:20 PM, "José Ventura" <st...@gmail.com> wrote:
> (perhaps this has already been discussed in the devs' mailing list, if so,
> forgive my ignorance).
>
> I'm not sure whether making the default value "on" will actually improve
> security as a whole. If a developer hasn't given thought to security, there
> are plenty of other pitfalls that may compromise an application (e.g. "where
> should I store the (previously unneeded yet now required) username and
> password?").
>
> On the other hand, if s/he did in fact think about security, then odds are
> that are a simple, concise documentation will point him/her to happily turn on
> the switch with minimum nuisance, and proceed to secure the rest of the
> application.
>
> @Roy:
> I believe that, since the change would happen in a next major release (11 vs.
> current 10.x), backwards compatibility wouldn't be *required* (but would
> certainly be *appreciated*).
>
> On Mon, Sep 19, 2011 at 4:55 PM, Rick Hillegas <ri...@oracle.com>
> wrote:
>> Hi Mike,
>>
>> Some comments inline...
>>
>> On 9/19/11 10:38 AM, Mike Matrigali wrote:
>>> I am not sure how it applies to all of these points, but I am wondering if
>>> secure by default should be implemented on a per database basis rather than
>>> a system level basis? It seems wierd that security could
>>> change based on how the next embedded startup set a flag.
>> I think that it should behave like derby.database.sqlAuthorization: once it's
>> been turned on it is stored in the database and you can't turn it off at the
>> system level. I agree that it would be weird to let the next user subvert the
>> security of your database by flipping a command line switch.
>>>
>>> What about having the property be part of what user requests at database
>>> creation time? And maybe allow some secure way either disable or enable it.
>>> The discussion could continue on what the default for a newly created
>>> database would be. At least for point 1-4 seems to make more sense, not
>>> sure about 5,6.
>>>
>>> I personally think many of these points make most sense for derby network
>>> server.
>> I'm also concerned about the embedded database on a USB stick. I could argue
>> that it is more vulnerable than the server-side database locked up in a
>> machine room.
>>> While many possibly get in the way for many zero-admin
>>> embedded applications.
>> I'm imagining that this change may be fairly unobtrusive. For an embedded
>> database which has only one user (the dbo), the big change is that the dbo
>> has to specify a username and password. There won't be any need to GRANT
>> access to other users so (2) won't be noticed. Items (3) and (4) won't burden
>> most applications. (5) and (6) are only issues for client/server usage.
>>> Since we have one codeline for the most part
>>> for both it is hard to have one default.
>> I agree that a common default would be best. It will make it easier to reason
>> about Derby's behavior and simplify our user guides.
>>
>> Thanks,
>> -Rick
>>
>>>
>>>
>>> Rick Hillegas wrote:
>>>> The Derby developers are considering introducing a single master security
>>>> property. Turning this property on will enable most Derby security
>>>> mechanisms:
>>>>
>>>> 1) Authentication - Will be on, requiring username/password credentials at
>>>> connection time. Derby will supply a default authentication mechanism.
>>>>
>>>> 2) SQL authorization - Will be on, hiding a user's data from other people.
>>>> In addition, Derby will support more SQL Standard protections for Java
>>>> routines.
>>>>
>>>> 3) File permissions - Will be tightened as described by DERBY-5363.
>>>>
>>>> 4) PUBLIC -This keyword will not be allowed as a user name.
>>>>
>>>> 5) SSL/TLS encryption - Will shield client/server traffic.
>>>>
>>>> 6) Server administration - Will require credentials.
>>>>
>>>> When the property is off, Derby will behave as it does today:
>>>> Authentication, authorization, and network encryption will be off, file
>>>> permissions will inherit defaults from the account which runs the VM,
>>>> PUBLIC will be a legal user name, and server administration won't need
>>>> credentials.
>>>>
>>>> This new master property will make it easier to configure a more secure
>>>> application. We want to introduce the property in an upcoming 10.x release,
>>>> where it will default to being off. That means that it won't cause
>>>> compatibility problems.
>>>>
>>>> Later on, we might change the default for this property so that it would
>>>> normally be turned on. This would make Derby more secure out of the box at
>>>> the cost of breaking existing applications. Many applications would need to
>>>> explicitly turn the property off in order to run as they did previously.
>>>> Release notes would document this behavioral change and we would bump the
>>>> major release id from 10 to 11 in order to call attention to the change.
>>>>
>>>> We would like your feedback on this trade-off between security out of the
>>>> box versus disruption. Should this extra security be enabled by default?
>>>>
>>>> Thanks,
>>>> -Rick
>>>>
>>>>
>>>
>>>
>>
>
>
iCrossing Privileged and Confidential Information
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of iCrossing. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Re: Derby secure by default
Posted by José Ventura <st...@gmail.com>.
(perhaps this has already been discussed in the devs' mailing list, if so,
forgive my ignorance).
I'm not sure whether making the default value "on" will actually improve
security as a whole. If a developer hasn't given thought to security, there
are plenty of other pitfalls that may compromise an application (e.g. "where
should I store the (previously unneeded yet now required) username and
password?").
On the other hand, if s/he did in fact think about security, then odds are
that are a simple, concise documentation will point him/her to happily turn
on the switch with minimum nuisance, and proceed to secure the rest of the
application.
@Roy:
I believe that, since the change would happen in a next major release (11
vs. current 10.x), backwards compatibility wouldn't be *required* (but would
certainly be *appreciated*).
On Mon, Sep 19, 2011 at 4:55 PM, Rick Hillegas <ri...@oracle.com>wrote:
> Hi Mike,
>
> Some comments inline...
>
> On 9/19/11 10:38 AM, Mike Matrigali wrote:
>
>> I am not sure how it applies to all of these points, but I am wondering if
>> secure by default should be implemented on a per database basis rather than
>> a system level basis? It seems wierd that security could
>> change based on how the next embedded startup set a flag.
>>
> I think that it should behave like derby.database.**sqlAuthorization: once
> it's been turned on it is stored in the database and you can't turn it off
> at the system level. I agree that it would be weird to let the next user
> subvert the security of your database by flipping a command line switch.
>
>>
>> What about having the property be part of what user requests at database
>> creation time? And maybe allow some secure way either disable or enable
>> it. The discussion could continue on what the default for a newly created
>> database would be. At least for point 1-4 seems to make more sense, not
>> sure about 5,6.
>>
>> I personally think many of these points make most sense for derby network
>> server.
>>
> I'm also concerned about the embedded database on a USB stick. I could
> argue that it is more vulnerable than the server-side database locked up in
> a machine room.
>
>> While many possibly get in the way for many zero-admin
>> embedded applications.
>>
> I'm imagining that this change may be fairly unobtrusive. For an embedded
> database which has only one user (the dbo), the big change is that the dbo
> has to specify a username and password. There won't be any need to GRANT
> access to other users so (2) won't be noticed. Items (3) and (4) won't
> burden most applications. (5) and (6) are only issues for client/server
> usage.
>
>> Since we have one codeline for the most part
>> for both it is hard to have one default.
>>
> I agree that a common default would be best. It will make it easier to
> reason about Derby's behavior and simplify our user guides.
>
> Thanks,
> -Rick
>
>
>>
>> Rick Hillegas wrote:
>>
>>> The Derby developers are considering introducing a single master security
>>> property. Turning this property on will enable most Derby security
>>> mechanisms:
>>>
>>> 1) Authentication - Will be on, requiring username/password credentials
>>> at connection time. Derby will supply a default authentication mechanism.
>>>
>>> 2) SQL authorization - Will be on, hiding a user's data from other
>>> people. In addition, Derby will support more SQL Standard protections for
>>> Java routines.
>>>
>>> 3) File permissions - Will be tightened as described by DERBY-5363.
>>>
>>> 4) PUBLIC -This keyword will not be allowed as a user name.
>>>
>>> 5) SSL/TLS encryption - Will shield client/server traffic.
>>>
>>> 6) Server administration - Will require credentials.
>>>
>>> When the property is off, Derby will behave as it does today:
>>> Authentication, authorization, and network encryption will be off, file
>>> permissions will inherit defaults from the account which runs the VM, PUBLIC
>>> will be a legal user name, and server administration won't need credentials.
>>>
>>> This new master property will make it easier to configure a more secure
>>> application. We want to introduce the property in an upcoming 10.x release,
>>> where it will default to being off. That means that it won't cause
>>> compatibility problems.
>>>
>>> Later on, we might change the default for this property so that it would
>>> normally be turned on. This would make Derby more secure out of the box at
>>> the cost of breaking existing applications. Many applications would need to
>>> explicitly turn the property off in order to run as they did previously.
>>> Release notes would document this behavioral change and we would bump the
>>> major release id from 10 to 11 in order to call attention to the change.
>>>
>>> We would like your feedback on this trade-off between security out of the
>>> box versus disruption. Should this extra security be enabled by default?
>>>
>>> Thanks,
>>> -Rick
>>>
>>>
>>>
>>
>>
>
Re: Derby secure by default
Posted by Rick Hillegas <ri...@oracle.com>.
On 9/19/11 2:54 PM, Mike Matrigali wrote:
> Rick Hillegas wrote:
>> Hi Mike,
>>
>> Some comments inline...
>>
>> On 9/19/11 10:38 AM, Mike Matrigali wrote:
>>> I am not sure how it applies to all of these points, but I am
>>> wondering if secure by default should be implemented on a per
>>> database basis rather than a system level basis? It seems wierd
>>> that security could
>>> change based on how the next embedded startup set a flag.
>> I think that it should behave like derby.database.sqlAuthorization:
>> once it's been turned on it is stored in the database and you can't
>> turn it off at the system level. I agree that it would be weird to
>> let the next user subvert the security of your database by flipping a
>> command line switch.
> I am trying to understand what happens when we change the default and
> a user upgrades to 11 and starts up on there existing database that
> has no
> authentication or authorization enabled. What is the proposed soft
> upgrade behavior? What is the proposed hard upgrade behavior?
To minimize disruption, I would recommend that the setting of the master
knob should not be affected by either soft or hard upgrade. If the knob
was off originally, it stays off after upgrade. And vice versa.
>
> This is a development detail but what is proposed for the existing derby
> set of tests, which I have to assume are about 99% not authenticated or
> authorized? Would we implement a way to run them both ways? Convert
> them all or most to run under new default?
My preference would be to make as many as possible run both ways.
>
>
Re: Derby secure by default
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas wrote:
> Hi Mike,
>
> Some comments inline...
>
> On 9/19/11 10:38 AM, Mike Matrigali wrote:
>> I am not sure how it applies to all of these points, but I am
>> wondering if secure by default should be implemented on a per database
>> basis rather than a system level basis? It seems wierd that security
>> could
>> change based on how the next embedded startup set a flag.
> I think that it should behave like derby.database.sqlAuthorization: once
> it's been turned on it is stored in the database and you can't turn it
> off at the system level. I agree that it would be weird to let the next
> user subvert the security of your database by flipping a command line
> switch.
I am trying to understand what happens when we change the default and a
user upgrades to 11 and starts up on there existing database that has no
authentication or authorization enabled. What is the proposed soft
upgrade behavior? What is the proposed hard upgrade behavior?
This is a development detail but what is proposed for the existing derby
set of tests, which I have to assume are about 99% not authenticated or
authorized? Would we implement a way to run them both ways? Convert
them all or most to run under new default?
Re: Derby secure by default
Posted by Rick Hillegas <ri...@oracle.com>.
Hi Mike,
Some comments inline...
On 9/19/11 10:38 AM, Mike Matrigali wrote:
> I am not sure how it applies to all of these points, but I am
> wondering if secure by default should be implemented on a per database
> basis rather than a system level basis? It seems wierd that security
> could
> change based on how the next embedded startup set a flag.
I think that it should behave like derby.database.sqlAuthorization: once
it's been turned on it is stored in the database and you can't turn it
off at the system level. I agree that it would be weird to let the next
user subvert the security of your database by flipping a command line
switch.
>
> What about having the property be part of what user requests at database
> creation time? And maybe allow some secure way either disable or
> enable it. The discussion could continue on what the default for a
> newly created database would be. At least for point 1-4 seems to make
> more sense, not sure about 5,6.
>
> I personally think many of these points make most sense for derby
> network server.
I'm also concerned about the embedded database on a USB stick. I could
argue that it is more vulnerable than the server-side database locked up
in a machine room.
> While many possibly get in the way for many zero-admin
> embedded applications.
I'm imagining that this change may be fairly unobtrusive. For an
embedded database which has only one user (the dbo), the big change is
that the dbo has to specify a username and password. There won't be any
need to GRANT access to other users so (2) won't be noticed. Items (3)
and (4) won't burden most applications. (5) and (6) are only issues for
client/server usage.
> Since we have one codeline for the most part
> for both it is hard to have one default.
I agree that a common default would be best. It will make it easier to
reason about Derby's behavior and simplify our user guides.
Thanks,
-Rick
>
>
> Rick Hillegas wrote:
>> The Derby developers are considering introducing a single master
>> security property. Turning this property on will enable most Derby
>> security mechanisms:
>>
>> 1) Authentication - Will be on, requiring username/password
>> credentials at connection time. Derby will supply a default
>> authentication mechanism.
>>
>> 2) SQL authorization - Will be on, hiding a user's data from other
>> people. In addition, Derby will support more SQL Standard protections
>> for Java routines.
>>
>> 3) File permissions - Will be tightened as described by DERBY-5363.
>>
>> 4) PUBLIC -This keyword will not be allowed as a user name.
>>
>> 5) SSL/TLS encryption - Will shield client/server traffic.
>>
>> 6) Server administration - Will require credentials.
>>
>> When the property is off, Derby will behave as it does today:
>> Authentication, authorization, and network encryption will be off,
>> file permissions will inherit defaults from the account which runs
>> the VM, PUBLIC will be a legal user name, and server administration
>> won't need credentials.
>>
>> This new master property will make it easier to configure a more
>> secure application. We want to introduce the property in an upcoming
>> 10.x release, where it will default to being off. That means that it
>> won't cause compatibility problems.
>>
>> Later on, we might change the default for this property so that it
>> would normally be turned on. This would make Derby more secure out of
>> the box at the cost of breaking existing applications. Many
>> applications would need to explicitly turn the property off in order
>> to run as they did previously. Release notes would document this
>> behavioral change and we would bump the major release id from 10 to
>> 11 in order to call attention to the change.
>>
>> We would like your feedback on this trade-off between security out of
>> the box versus disruption. Should this extra security be enabled by
>> default?
>>
>> Thanks,
>> -Rick
>>
>>
>
>
Re: Derby secure by default
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I am not sure how it applies to all of these points, but I am wondering
if secure by default should be implemented on a per database basis
rather than a system level basis? It seems wierd that security could
change based on how the next embedded startup set a flag.
What about having the property be part of what user requests at database
creation time? And maybe allow some secure way either disable or enable
it. The discussion could continue on what the default for a newly
created database would be. At least for point 1-4 seems to make more
sense, not sure about 5,6.
I personally think many of these points make most sense for derby
network server. While many possibly get in the way for many zero-admin
embedded applications. Since we have one codeline for the most part
for both it is hard to have one default.
Rick Hillegas wrote:
> The Derby developers are considering introducing a single master
> security property. Turning this property on will enable most Derby
> security mechanisms:
>
> 1) Authentication - Will be on, requiring username/password credentials
> at connection time. Derby will supply a default authentication mechanism.
>
> 2) SQL authorization - Will be on, hiding a user's data from other
> people. In addition, Derby will support more SQL Standard protections
> for Java routines.
>
> 3) File permissions - Will be tightened as described by DERBY-5363.
>
> 4) PUBLIC -This keyword will not be allowed as a user name.
>
> 5) SSL/TLS encryption - Will shield client/server traffic.
>
> 6) Server administration - Will require credentials.
>
> When the property is off, Derby will behave as it does today:
> Authentication, authorization, and network encryption will be off, file
> permissions will inherit defaults from the account which runs the VM,
> PUBLIC will be a legal user name, and server administration won't need
> credentials.
>
> This new master property will make it easier to configure a more secure
> application. We want to introduce the property in an upcoming 10.x
> release, where it will default to being off. That means that it won't
> cause compatibility problems.
>
> Later on, we might change the default for this property so that it would
> normally be turned on. This would make Derby more secure out of the box
> at the cost of breaking existing applications. Many applications would
> need to explicitly turn the property off in order to run as they did
> previously. Release notes would document this behavioral change and we
> would bump the major release id from 10 to 11 in order to call attention
> to the change.
>
> We would like your feedback on this trade-off between security out of
> the box versus disruption. Should this extra security be enabled by
> default?
>
> Thanks,
> -Rick
>
>
Re: Derby secure by default
Posted by Peter Ondruška <pe...@kaibo.eu>.
Rick, I’d vote for secure by default in v.11. Thanks
On Mon, Sep 19, 2011 at 6:39 PM, Rick Hillegas <ri...@oracle.com> wrote:
> The Derby developers are considering introducing a single master security
> property. Turning this property on will enable most Derby security
> mechanisms:
>
> 1) Authentication - Will be on, requiring username/password credentials at
> connection time. Derby will supply a default authentication mechanism.
>
> 2) SQL authorization - Will be on, hiding a user's data from other people.
> In addition, Derby will support more SQL Standard protections for Java
> routines.
>
> 3) File permissions - Will be tightened as described by DERBY-5363.
>
> 4) PUBLIC -This keyword will not be allowed as a user name.
>
> 5) SSL/TLS encryption - Will shield client/server traffic.
>
> 6) Server administration - Will require credentials.
>
> When the property is off, Derby will behave as it does today:
> Authentication, authorization, and network encryption will be off, file
> permissions will inherit defaults from the account which runs the VM, PUBLIC
> will be a legal user name, and server administration won't need credentials.
>
> This new master property will make it easier to configure a more secure
> application. We want to introduce the property in an upcoming 10.x release,
> where it will default to being off. That means that it won't cause
> compatibility problems.
>
> Later on, we might change the default for this property so that it would
> normally be turned on. This would make Derby more secure out of the box at
> the cost of breaking existing applications. Many applications would need to
> explicitly turn the property off in order to run as they did previously.
> Release notes would document this behavioral change and we would bump the
> major release id from 10 to 11 in order to call attention to the change.
>
> We would like your feedback on this trade-off between security out of the
> box versus disruption. Should this extra security be enabled by default?
>
> Thanks,
> -Rick
>
>
RE: Derby secure by default
Posted by "Bergquist, Brett" <BB...@canoga.com>.
Off by default for the release coming out. On by default if you want at the next major release.
-----Original Message-----
From: Rick Hillegas [mailto:rick.hillegas@oracle.com]
Sent: Monday, September 19, 2011 12:39 PM
To: Derby Discussion
Subject: Derby secure by default
The Derby developers are considering introducing a single master
security property. Turning this property on will enable most Derby
security mechanisms:
1) Authentication - Will be on, requiring username/password credentials
at connection time. Derby will supply a default authentication mechanism.
2) SQL authorization - Will be on, hiding a user's data from other
people. In addition, Derby will support more SQL Standard protections
for Java routines.
3) File permissions - Will be tightened as described by DERBY-5363.
4) PUBLIC -This keyword will not be allowed as a user name.
5) SSL/TLS encryption - Will shield client/server traffic.
6) Server administration - Will require credentials.
When the property is off, Derby will behave as it does today:
Authentication, authorization, and network encryption will be off, file
permissions will inherit defaults from the account which runs the VM,
PUBLIC will be a legal user name, and server administration won't need
credentials.
This new master property will make it easier to configure a more secure
application. We want to introduce the property in an upcoming 10.x
release, where it will default to being off. That means that it won't
cause compatibility problems.
Later on, we might change the default for this property so that it would
normally be turned on. This would make Derby more secure out of the box
at the cost of breaking existing applications. Many applications would
need to explicitly turn the property off in order to run as they did
previously. Release notes would document this behavioral change and we
would bump the major release id from 10 to 11 in order to call attention
to the change.
We would like your feedback on this trade-off between security out of
the box versus disruption. Should this extra security be enabled by default?
Thanks,
-Rick
Re: Derby secure by default
Posted by "Dag H. Wanvik" <da...@oracle.com>.
On 9/20/2011 12:20 AM, Mike Matrigali wrote:
> I think that new features that rick is proposing are valuable to some
> set of Derby users, and welcome their inclusion in Derby. Having one
> flag to enable a set of secure oriented features also seems reasonable
> as long as users can still pick and choose if they don't want the
> complete set. I don't think
> they should be made the default in the current release or a future
> release.
>
> I believe zero admin upgrade/backward compatibility has been a great
> feature for Derby so far and we should do whatever we can to not break
> it going forward. It seems like applications that need this feature set
> can set the appropriate flag going forward and then do the work to
> properly configure authentication and authorization, ssl encryption
> passwords, and other server administration. Since there is extra work
> necessary to use these features it seems reasonable to put to work on
> these applications to set the flag rather than put the work on the
> zero-admin applications that do not need these features.
>
> By default Derby should be zero admin and thus default to not requiring
> this extra administration.
I agree that there is no "secure-by-default" in general, a really secure
solution needs careful planning and a good understanding of the issues
and the technology being used. However, that is not necessarily a good
reason to "leave all doors open" if the user takes no special action to
close them.
If the database is protected by application level security (as often is
the case for embedded Derby deployments), this is less of an issue.
I would be OK with keeping the current behavior the default for embedded
Derby.
Again, I am less convinced by the argument in a client/server
deployment: I believe the current behavior there is unwise. I believe it
would be acceptable/good
to close the "open doors" in a major release upgrade (11.0) - with a
goal to a keeping the administration to a minimum (minimal admin is nice
if you want a secure detabase, too..), both for secure deployments [1]
and not ("turn one knob to get rid of it").
[1] Not sure what the minimums is, possibly creating at least one user,
generating/installing SSL certs?
Thanks,
Dag
>
>
>> ------------------------------------------------------------------------
>> *From: *"Rick Hillegas" <ri...@oracle.com>
>> *To: *"Derby Discussion" <de...@db.apache.org>
>> *Sent: *Monday, September 19, 2011 12:39:07 PM
>> *Subject: *Derby secure by default
>>
>> The Derby developers are considering introducing a single master
>> security property. Turning this property on will enable most Derby
>> security mechanisms:
>>
>> 1) Authentication - Will be on, requiring username/password credentials
>> at connection time. Derby will supply a default authentication
>> mechanism.
>>
>> 2) SQL authorization - Will be on, hiding a user's data from other
>> people. In addition, Derby will support more SQL Standard protections
>> for Java routines.
>>
>> 3) File permissions - Will be tightened as described by DERBY-5363.
>>
>> 4) PUBLIC -This keyword will not be allowed as a user name.
>>
>> 5) SSL/TLS encryption - Will shield client/server traffic.
>>
>> 6) Server administration - Will require credentials.
>>
>> When the property is off, Derby will behave as it does today:
>> Authentication, authorization, and network encryption will be off, file
>> permissions will inherit defaults from the account which runs the VM,
>> PUBLIC will be a legal user name, and server administration won't need
>> credentials.
>>
>> This new master property will make it easier to configure a more secure
>> application. We want to introduce the property in an upcoming 10.x
>> release, where it will default to being off. That means that it won't
>> cause compatibility problems.
>>
>> Later on, we might change the default for this property so that it would
>> normally be turned on. This would make Derby more secure out of the box
>> at the cost of breaking existing applications. Many applications would
>> need to explicitly turn the property off in order to run as they did
>> previously. Release notes would document this behavioral change and we
>> would bump the major release id from 10 to 11 in order to call attention
>> to the change.
>>
>> We would like your feedback on this trade-off between security out of
>> the box versus disruption. Should this extra security be enabled by
>> default?
>>
>> Thanks,
>> -Rick
>>
>
Re: Derby secure by default
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Roy.Minet@comcast.net wrote:
> Installing a new version should always be backward compatible and not
> break anything in existing applications. If things don't work this way,
> it's bound to be (unncessarily) disruptive to some, and especially those
> less sophisticated and less able to figure out and fix problems. I see
> no reason why anyone who wishes to utilize the new capabilities would
> have any problem with setting the new property when they are ready to do
> so. Security is obviously important, especially for networked
> applications. I think it's also important not to do anything that
> interferes with embedded applications designed to require ZERO
> administration.
>
+1
I think that new features that rick is proposing are valuable to some
set of Derby users, and welcome their inclusion in Derby. Having one
flag to enable a set of secure oriented features also seems reasonable
as long as users can still pick and choose if they don't want the
complete set. I don't think
they should be made the default in the current release or a future release.
I believe zero admin upgrade/backward compatibility has been a great
feature for Derby so far and we should do whatever we can to not break
it going forward. It seems like applications that need this feature set
can set the appropriate flag going forward and then do the work to
properly configure authentication and authorization, ssl encryption
passwords, and other server administration. Since there is extra work
necessary to use these features it seems reasonable to put to work on
these applications to set the flag rather than put the work on the
zero-admin applications that do not need these features.
By default Derby should be zero admin and thus default to not requiring
this extra administration.
> ------------------------------------------------------------------------
> *From: *"Rick Hillegas" <ri...@oracle.com>
> *To: *"Derby Discussion" <de...@db.apache.org>
> *Sent: *Monday, September 19, 2011 12:39:07 PM
> *Subject: *Derby secure by default
>
> The Derby developers are considering introducing a single master
> security property. Turning this property on will enable most Derby
> security mechanisms:
>
> 1) Authentication - Will be on, requiring username/password credentials
> at connection time. Derby will supply a default authentication mechanism.
>
> 2) SQL authorization - Will be on, hiding a user's data from other
> people. In addition, Derby will support more SQL Standard protections
> for Java routines.
>
> 3) File permissions - Will be tightened as described by DERBY-5363.
>
> 4) PUBLIC -This keyword will not be allowed as a user name.
>
> 5) SSL/TLS encryption - Will shield client/server traffic.
>
> 6) Server administration - Will require credentials.
>
> When the property is off, Derby will behave as it does today:
> Authentication, authorization, and network encryption will be off, file
> permissions will inherit defaults from the account which runs the VM,
> PUBLIC will be a legal user name, and server administration won't need
> credentials.
>
> This new master property will make it easier to configure a more secure
> application. We want to introduce the property in an upcoming 10.x
> release, where it will default to being off. That means that it won't
> cause compatibility problems.
>
> Later on, we might change the default for this property so that it would
> normally be turned on. This would make Derby more secure out of the box
> at the cost of breaking existing applications. Many applications would
> need to explicitly turn the property off in order to run as they did
> previously. Release notes would document this behavioral change and we
> would bump the major release id from 10 to 11 in order to call attention
> to the change.
>
> We would like your feedback on this trade-off between security out of
> the box versus disruption. Should this extra security be enabled by default?
>
> Thanks,
> -Rick
>
Re: Derby secure by default
Posted by Ro...@comcast.net.
Installing a new version should always be backward compatible and not break anything in existing applications. If things don't work this way, it's bound to be (unncessarily) disruptive to some, and especial ly those less sophisticated and less able to figure out and fix problems. I see no reason why anyon e who wishes to utilize the new capabil ities would have any problem with setting the new property when they are ready to do so. Security is obviously important, especially for networked applications. I think it's also important not to do anything that interferes with embedded applications designed to require ZERO administration.
----- Original Message -----
From: "Rick Hillegas" <ri...@oracle.com>
To: "Derby Discussion" <de...@db.apache.org>
Sent: Monday, September 19, 2011 12:39:07 PM
Subject: Derby secure by default
The Derby developers are considering introducing a single master
security property. Turning this property on will enable most Derby
security mechanisms:
1) Authentication - Will be on, requiring username/password credentials
at connection time. Derby will supply a default authentication mechanism.
2) SQL authorization - Will be on, hiding a user's data from other
people. In addition, Derby will support more SQL Standard protections
for Java routines.
3) File permissions - Will be tightened as described by DERBY-5363.
4) PUBLIC -This keyword will not be allowed as a user name.
5) SSL/TLS encryption - Will shield client/server traffic.
6) Server administration - Will require credentials.
When the property is off, Derby will behave as it does today:
Authentication, authorization, and network encryption will be off, file
permissions will inherit defaults from the account which runs the VM,
PUBLIC will be a legal user name, and server administration won't need
credentials.
This new master property will make it easier to configure a more secure
application. We want to introduce the property in an upcoming 10.x
release, where it will default to being off. That means that it won't
cause compatibility problems.
Later on, we might change the default for this property so that it would
normally be turned on. This would make Derby more secure out of the box
at the cost of breaking existing applications. Many applications would
need to explicitly turn the property off in order to run as they did
previously. Release notes would document this behavioral change and we
would bump the major release id from 10 to 11 in order to call attention
to the change.
We would like your feedback on this trade-off between security out of
the box versus disruption. Should this extra security be enabled by default?
Thanks,
-Rick