db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2196) Run standalone network server with security manager by default
Date Thu, 08 Feb 2007 01:39:05 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471174

Daniel John Debrunner commented on DERBY-2196:

> I think that that hole exists regardless of whether the black-hat jar file is ${derby.install.url}
or ${derby.install.url}/lib/derby.jar.

I think that  a codebase in a policy file of ${derby.install.url} is a *much* bigger hole
than ${derby.install.url}/lib/derby.jar
and has the potential to be beneifical to hostile clients.
The reasons is that if I can modify ${derby.install.url} than I can point to any code including
the special token of *all* code.

If I have the ability to set a system property on a remote host but don't have the ability
to install software there, then I can could potentially use a remote server to grant a wide
range of permissions to all code including SQL Java routines, thus allowing remote SQL Java
routine defined by me remotely to have a wide range of permissions.

Limiting the hole to jar files called derby.jar in a lib folder is a much smaller exposure
and cannot be exploited by SQL Java routines.

Maybe a remote client having the ability to set a system property is somewhat unlikely, but
to be clear it need not be the permission to set all system properties, just one specific
one, or the ability to set one in the derby.* namespace. Thus someone else may set up a policy
file that allows some code to set derby.* properties as system properties and not realize
they could have opened up everything.

We don't have to expose these properties in the template policy, it could have its codebase
manipulated in the build process to be something like (actual text): replace_with_path_to_derby_install/lib/derby.jar
Ie. something that forces the application developer to edit it.
It is a template for a policy file, that we expect the user to modify anyway.

> Run standalone network server with security manager by default
> --------------------------------------------------------------
>                 Key: DERBY-2196
>                 URL: https://issues.apache.org/jira/browse/DERBY-2196
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server, Security
>            Reporter: Daniel John Debrunner
>         Assigned To: Rick Hillegas
>         Attachments: derby-2196-01-print-01.diff, derby-2196-01-print-02.diff, derby-2196-01-print-03.diff,
secureServer.html, secureServer.html, secureServer.html, secureServer.html, secureServer.html,
> From an e-mail discussion:
> ... Derby should match the security  provided by typical client server systems such as
DB2, Oracle, etc. I 
> think in this case system/database owners are trusting the database 
> system to ensure that their system cannot be attacked. So maybe if Derby 
> is booted as a standalone server with no security manager involved, it 
> should install one with a default security policy. Thus allowing Derby 
> to use Java security manager to manage system privileges but not 
> requiring everyone to become familiar with them.
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/%3c4582FE67.7040308@apache.org%3e
> I imagine such a policy would allow any access to databases under derby.system.home and/or
> By standalone I mean the network server was started though the main() method (command

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message