[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464260
]
Daniel John Debrunner commented on DERBY-2109:
----------------------------------------------
I agree that supporting a more flexible Principle scheme could be added later,
I don't think I see any issues with having a database login always having a
DatabasePrinciple associated with it. I think for forwards compatibility that
will be required, i.e. in the future methods in UserAuthenticator may be able
to add Principles to the Subject, but will not be able to remove the
DatabasePrinciple. I do think that Derby's internal implementation should not
be relying on DatabasePrinciple, e.g. all fields, variables, parameters etc.
are declared as Principle and DatabasePrinciple should only appear when the
actual instance is created using new DatabsaePrinciple.
A few new thoughts did come out of your comment:
- with Java routines this spec does not indicate that the routine will run
with the Subject set to one including the DatabasePrinciple. I don't think it
needs to but it is a direction that may be required in the future. This would
allow database user based granting on permissions in Java routines which might
be useful since the only way to grant java permissions to code in installed jar
files is to sign the jar and grant permissions to the signer.
- related to the last point, the visibility of the current Subject containing
its DatabasePrinciple, might be clear to state that currently there is no
visibility to user code of the Subject containing its DatabasePrinciple.
- Derby supports multiple databases within a system and per-database
authentication. This means that ALICE in one database can be a different
identity to ALICE in another database. DatabasePrinciple does not account for
this. This may have the potential to be a security hole, though maybe not with
the limited set of permissions today. Basic idea would be.
ALICE has some permissions that FRED does not have.
FRED only has permission to create databases
FRED can create a database with BUILTIN authentication and a user ALICE to
pick up any permissions granted to ALICE.
It might be ok with the proposed changes because the identity is also
authenticated in that specific domain, e.g. I assume to be ALICE to shutdown an
engine or create a database one must be authenticated against the system
authentication. Thus the ALICE from FRED's database would not be able to log
into take advantage of the shutdown engine granted to the real ALICE.
The problems come when the policy file contains entries that are not linked to
database authentication, e.g. to allow specific actions in routines, e.g. grant
permission to ALICE to read '/etc/password', that could be hijacked by FRED's
ALICE if the routine was run as the DatabasePrinciple(FRED).
I think this needs some thought, possible paths are: not an issue,
DatabasePrinciple with database location path or good documentation the scope
of DatabasePrinciple.
> System privileges
> -----------------
>
> Key: DERBY-2109
> URL: https://issues.apache.org/jira/browse/DERBY-2109
> Project: Derby
> Issue Type: New Feature
> Components: Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Fix For: 10.3.0.0
>
> Attachments: systemPrivs.html, systemPrivs.html
>
>
> Add mechanisms for controlling system-level privileges in Derby. See the
> related email discussion at
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more
> secure in a client/server configuration. I'd like to plug more client/server
> security holes in 10.3. In particular, I'd like to focus on authorization
> issues which the ANSI spec doesn't address.
> Here are the important issues which came out of the email discussion.
> Missing privileges that are above the level of a single database:
> - Create Database
> - Shutdown all databases
> - Shutdown System
> Missing privileges specific to a particular database:
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
> - Create (in that Database) Java Plugins (currently Functions/Procedures,
> but someday Aggregates and VTIs)
> Note that 10.2 gave us GRANT/REVOKE control over the following
> database-specific issues, via granting execute privilege to system
> procedures:
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table
> In addition, since 10.0, the privilege of connecting to a database has been
> controlled by two properties (derby.database.fullAccessUsers and
> derby.database.defaultConnectionMode) as described in the security section of
> the Developer's Guide (see
> http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
