persistence@glassfish.java.net

Re: questions about fixing issue 924

From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Tue, 29 Aug 2006 13:37:04 -0700

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).

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.

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
>>
>>
>>
>