persistence@glassfish.java.net

Re: questions about fixing issue 924

From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Tue, 29 Aug 2006 13:45:40 -0700

Hi,

On Aug 29, 2006, at 1:37 PM, Marina Vatkina wrote:

> Hi Tom,
>
> This is what I learned so far:
>
> 1) (From Java SE expert) default permissions granted by the <java-
> home>/lib/security/java.policy in Sun implementation.
> In 5.0u7, they were:
>
> permission java.util.PropertyPermission
>
> "java.version", "read";
> "java.vendor", "read";
> "java.vendor.url", "read";
> "java.class.version", "read";
> "os.name", "read";
> "os.version", "read";
> "os.arch", "read";
> "file.separator", "read";
> "path.separator", "read";
> "line.separator", "read";
>
> "java.specification.version", "read";
> "java.specification.vendor", "read";
> "java.specification.name", "read";
>
> "java.vm.specification.version", "read";
> "java.vm.specification.vendor","read";
> "java.vm.specification.name", "read";
> "java.vm.version", "read";
> "java.vm.vendor", "read";
> "java.vm.name", "read";
>
> 2) (From GF security expert) In GF we do grant all code the ability
> to read all System properties (which arguably carries with it some
> Security liabilities).

Does this include application code as well as the application server
code? If I recall the server specification correctly, this would be a
violation of the specification.

>
> Questions:
>
> a). Do you still want to have doPrivileged block around all of
> them? Note that some are in antlr code and might require such block
> in the parser instead.

If the policy is to allow all application server code to access
properties, and deny application code, the doPrivileged is still needed.

Craig
>
> b). Do you see a problem if I replace in TopLinkWeaver
> System.getProperties().getProperty(...) with System.getProperty(...)?
>
> thanks,
> -marina
>
>
> Tom Ware wrote:
>> I am ok with doing option a.
>> A couple of things you should know...
>> There is unprivileged access to the following properties in other
>> areas of TopLink. Oracle AS solves this issue by granting
>> permission to it's applications to access those properties.
>> - line.separator
>> - java.version
>> - user.dir
>> - file.separator
>> - path.separator
>> - java.io.tmpdir
>> -Tom
>> Marina Vatkina wrote:
>>> Hi Tom,
>>>
>>> Do you expect the fix for this issue by a) adding a doPrivileged
>>> block around
>>> System.getProperties() or b) by adding a new class and
>>> corresponding methods
>>> in TopLink oracle/toplink/essentials/internal/security package?
>>>
>>> It's easy to do a), but I have a problem with option b) - it
>>> allows unauthorized
>>> access to a malicious code: the jars under GF have all
>>> permissions, plus a
>>> public method with doPrivileged block will block further security
>>> access
>>> validation.
>>>
>>> Do you see a problem if I do a) and file a separate bug for b)?
>>>
>>> thanks,
>>> -marina
>>>
>>>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!