JEP Review Request: Improve Security Manager Performance

[David M. Lloyd]

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

>>                                                             It's not
>> like normal directly invokable methods where the user can pass in
>> arguments and get return values from code that runs in a privileged
>> context.  [...]
>
> Static initialisers deal with globals, and they're a bit worse than
> arguments.

That generalization is meaningless.

>>                        I don't think anyone ever said "Oh, it's a good
>> thing I got that AccessControlException in my static initializer; now I
>> know that doing XYZ needed a privileged block".
>
> You don't need "in my static initializer" in that sentence.

This is also meaningless.

>>
>> Exactly - in this case I would even expect that you could separately
>> annotate each static init with its privileges.  The important thing
>> would still be that the compiler can do this without constructing a new
>> class for each chunk (or even a lambda if it could be avoided).
>
> I guess you could do that by generating synthetic methods where necessary.

Not sure how or why that helps?

-- 
- DML