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
