JEP Review Request: Improve Security Manager Performance

[Peter Levart]

On 07/28/2014 03:34 PM, David M. Lloyd wrote:
> On 07/24/2014 04:17 AM, Tom Hawtin wrote:
>> On 23/07/2014 14:40, David M. Lloyd wrote:
>>> On 07/23/2014 07:07 AM, Tom Hawtin wrote:
>>>> On 23/07/2014 05:26, David M. Lloyd wrote:
>>
>>>>> • Always have static initialization blocks be privileged (this does
>>>>> require users to be cognizant of this fact when writing static 
>>>>> blocks)
>>>>
>>>> If we were following "secure by default", this would break it. It 
>>>> turns
>>>> out having a static initaliser run with an unprivileged acc highlights
>>>> code that is doing something naughty.
>>>
>>> I thought this mindset might dominate, which is unfortunate. In
>>> practice, it is far better for code to be predictable, concise, and
>>> clear.  It does not really make any sense to have random security
>>> contexts in place and then call it "secure"; it makes more sense to 
>>> just
>>> tell people "hey your static initializers are privileged".
>>
>> I'm not suggesting that the random context is a good design. ("Random"
>> in the sense that an adversary can often arrange for a trusted context
>> when the code expects typical untrusted.) Years ago I suggested the same
>> thing. I'm glad that it was rejected due to subsequent experience and a
>> bit of reflection.
>
> Logically speaking there is no weakness here though.
>
> In order to do privileged things (in static init), you must use a 
> privileged block.  You must always assume that the context is random 
> (because it is).  Thus static blocks are already using privileged blocks.

But what to do if you don't want to do privileged things and play safe. 
Would following help?

public class SomeClass {
     static {
         AccessController.doPrivileged(
                 (PrivilegedAction<Void>) ::unprivilegedInit,
                 new AccessControlContext(new ProtectionDomain[] { new 
ProtectionDomain(null, null) })
         );
     }

     private static void unprivilegedInit() {
         ...
     }

...


I guess the majority of static initializers don't do privileged things 
so they should not be privileged by default. I suspect it would be 
better for static initializers to behave like the above code - the 
contrary to what David would like them to be...


Regards, Peter

> There is no meaningful way (in a static init) to test that a caller 
> has permission to cause a class to initialize.  Therefore every 
> privileged block is superfluous and wasteful.  There is no logically 
> provable benefit to requiring the privileged block on static init - 
> only superstition.  There is no attack vector here that is not already 
> here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140728/089acbae/attachment.htm>