Re: Derby secure by default
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
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: noneThis is the wide-open security behavior of the 10.x series. basicThis 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
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 rick.hille...@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
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 Hillegasrick.hille...@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: noneThis is the wide-open security behavior of the 10.x series. basicThis 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
Re: Derby secure by default
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 rick.hille...@oracle.com *To: *Derby Discussion derby-user@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
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
Rick, I’d vote for secure by default in v.11. Thanks On Mon, Sep 19, 2011 at 6:39 PM, Rick Hillegas rick.hille...@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
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.hille...@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
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
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 rick.hille...@oracle.com To: Derby Discussion derby-user@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
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
(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 rick.hille...@oracle.comwrote: 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
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.ne...@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 rick.hille...@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.
Re: Derby secure by default
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
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
roy.mi...@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 rick.hille...@oracle.com *To: *Derby Discussion derby-user@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
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
