(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 <[email protected]>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 >>> >>> >>> >> >> >
