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. 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.
