db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5548) Implement a GRANT/REVOKE scheme for authorizing system-wide operations
Date Thu, 17 May 2012 18:16:10 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278048#comment-13278048
] 

Rick Hillegas commented on DERBY-5548:
--------------------------------------

Here is a more flexible proposal. The idea is to let applications use any authentication scheme
they want (including LDAP) and still let them...

1) Code their own rules for authorizing system-wide operations...

2) or use a Derby-supplied NATIVE scheme which administers system-wide permissions via GRANT/REVOKE.

A sketch of this scheme follows.

----- (1) APPLICATION-SUPPLIED AUTHORIZATION CODE --------------

We expose the following interface in org.apache.derby.security:

public interface OperationAuthorizer
{
    // system-wide operations
    public  static  final   int CREATE_DATABASE = 0; // includes ability to restore databases
    public  static  final   int SHUTDOWN_ENGINE = 1;
    public  static  final   int ADMINISTER_NETWORK_SERVER = 2; // includes ability to start
and stop the network server and toggle tracing

    /** Returns true if the user is authorized to perform the operation */
    public  boolean isAuthorized
    (
        int operation,
        String userName
    )
    throws SQLException;
}

We introduce a new Derby property...

    derby.system.authorizer

...which may take the following values:

i) NONE: (this is the default value, which installs an OperationAuthorizer allowing all users
to perform all system-wide operations).

ii) The name of an application-supplied class which implements OperationAuthorizer.

iii) NATIVE:$authorizationDB (this forwards authorization requests to the $authorizationDB
as described below).


----- (2) NATIVE AUTHORIZATION --------------


We introduce a new value for SYSPERMS.OBJECTTYPE:

    DERBY

We introduce the following new values for SYSPERMS.PERMISSIONS:

    CREATE_DATABASE
    SHUTDOWN_ENGINE
    ADMINISTER_NETWORK_SERVER


Then the DBO in a database can issue commands like this:

    grant create_database on derby to dbo_role;

    grant shutdown_engine on derby to sysadmin_role;

By default, a DBO  is granted all system-wide permissions.

We introduce the following vti, which returns a ResultSet having the shape of SYSPERMS. This
vti returns all SYSPERMS permissions which have been granted to the given grantee or to a
role which the grantee can set:

    syscs_diag.perms_closure( grantee varchar( 128 ) ) ...

When derby.system.authorizer=NATIVE:$authorizationDB is set and a user attempts a system-wide
operation, the NATIVE authorization service does the following:

1) Connects to $authorizationDB using the user's supplied credentials.

2) Runs the following query in the resulting connection. Here ? is stuffed with the permission
we're looking for (e.g., CREATE_DATABASE):

  select count(*) from table ( syscs_diag.perms_closure( current_user ) ) t
  where t.permission = ?;

3) If the query result is non-zero, then the system-wide operation is allowed.

                
> Implement a GRANT/REVOKE scheme for authorizing system-wide operations
> ----------------------------------------------------------------------
>
>                 Key: DERBY-5548
>                 URL: https://issues.apache.org/jira/browse/DERBY-5548
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Rick Hillegas
>
> This is an alternative proposal for how we could authorize system-wide operations. Those
operations are:
> o Database creation
> o Database restoration
> o Engine shutdown
> o Server shutdown
> o Server startup
> Currently, any valid Derby user can execute all of those operations. This leaves Derby-powered
applications vulnerable to resource-exhaustion and denial-of-service attacks. There is no
reason that a data-entry clerk should have the power to bring down an enterprise-wide application.
> DERBY-2109 describes our first attempt to implement authorization for system-wide operations.
The work on that issue was never completed. Under the DERBY-2109 scheme, system-wide operations
are authorized by entries in the application's Java security policy. That scheme has some
shortcomings:
> 1) Configuring Java security policy files is tricky. It is easy to make mistakes. Furthermore,
the policy file reader does not give you much assistance in tracking down and correcting those
mistakes.
> 2) The scheme only grants privileges to individual users. You can't grant system-wide
privileges to roles.
> The following alternative scheme builds on the idea of a Credentials DB, introduced by
the work on DERBY-866. Thanks to Dag for helping puzzle through these issues.
> -------------------------------------------------
> A system-wide Credentials DB could be used to store system-wide privileges in addition
to system-wide credentials. 2 variants of this proposal have been considered:
> i) We could introduce some new privileges, extensions to the SQL Standard privilege set.
The DBO of the Credentials DB could grant and revoke these privileges to/from users/roles:
>    DERBY_CREATE_DATABASE
>    DERBY_RESTORE_DATABASE
>    DERBY_SHUTDOWN_ENGINE
>    DERBY_SHUTDOWN_SERVER
>    DERBY_STARTUP_SERVER
> ii) Alternatively, we could introduce some new system routines to represent the system-wide
operations. Privilege to perform the operations would depend on whether a user/role had been
granted EXECUTE privilege on the corresponding routines:
>    syscs_util.syscs_create_database()
>    syscs_util.syscs_restore_database()
>    syscs_util.syscs_shutdown_engine()
>    syscs_util.syscs_shutdown_server()
>    syscs_util.syscs_startup_server()
> A new Derby property would configure whether this authorization scheme should be used.
This property would be set at the system level, that is, on the JVM properties or in derby.properties:
>   -Dderby.system.authorization=NATIVE
> If we implemented this scheme in the 10.9 timeframe, then we could default it to being
on whenever NATIVE authentication was on at the system level. For instance, for an application
with one database, myDB, NATIVE authentication and authorization would both be switched on
by setting one knob:
>   -Dderby.authentication.provider=NATIVE:myDB
> We could also introduce a new attribute on the connection URL:
>   role=roleName
> Here for instance would be the processing flow when a user tried to connect with the
following URL:
>   jdbc:derby:;shutdown=true;user=alice;password=alicepassword;role=sysadmin
> a) A connection would be opened to the Credentials DB using alice's credentials.
> b) On that connection, an attempt would be made to "set role sysadmin". If that failed,
the shutdown would error out.
> c) If the role change succeeded, Derby would verify whether alice or the sysadmin role
had been granted privilege to shutdown the engine. If not, the shutdown would error out.
> d) If the privilege had been granted, then orderly shutdown would be performed.
> It should be possible to make this authorization scheme work regardless of the authentication
scheme being used. That is, it could work regardless of whether you were using LDAP, custom,
or NATIVE authentication.
> A key advantage of this scheme is that it would be easy to administer using familiar
GRANT/REVOKE commands.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message