[
https://issues.apache.org/jira/browse/DERBY-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510503
]
Kathey Marsden commented on DERBY-2436:
---------------------------------------
Mike asked:
>I am not sure how this maps to specific security policies. What do we do with
>user java functions/procedures? How do we >handle
>security for those procedures reading/writing database files.
I think that it is controlled by the permissions for whatever jar contains the
procedure. I am not sure about jars in the database though.
>it seems like import should read files using no policy that has been granted
>to derby for database processing, and >similarly export should write files
>using no policy that has been granted to derby for database processing.
We grant
permission java.io.FilePermission "${derby.system.home}","read"; to derby.jar
in order to grant read permission to derby.properties and the directory
contents. Using the anti-policy philosophy, we would need to disallow
completely access to derby.system.home and perhaps user.home if
derby.system.home is not set. I think that may be too restrictive and cause
regression if users put files user.dir or derby.system.home. As long as we
restrict read/write of derby.properties, derby.log and database directories I
think we should be covered. How to do this, I do not yet know.
> SYSCS_IMPORT_TABLE can be used to read derby files
> --------------------------------------------------
>
> Key: DERBY-2436
> URL: https://issues.apache.org/jira/browse/DERBY-2436
> Project: Derby
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.2.1, 10.2.1.6, 10.3.1.0
> Reporter: Daniel John Debrunner
> Priority: Critical
>
> There are no controls over which files SYSCS_IMPORT_TABLE can read, thus
> allowing any user that has permission to execute the procedure to try and
> access information that they have no permissions to do so. E.g. even with the
> secure-by-default network server I can execute three lines of SQL to view to
> contents of derby.properties, thus seeing passwords of other users, or the
> address of the ldap server.
> create table t (c varchar(32000));
> CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(NULL, 'T', 'derby.properties', NULL, NULL,
> 'ISO8859_1', 0);
> ij> select * from T;
> C
> ----------------------------------------------
> derby.connection.requireAuthentication=true
> derby.authentication.provider=BUILTIN
> derby.user.SA=sapwd
> derby.user.MARY=marypwd
> Also a similar trick could be attempted against the actual data files,
> allowing a user to attempt to bypass grant/revoke security, especially no
> that binary data can be exported/imported.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
