JEP Review Request: Improve Security Manager Performance

Tom Hawtin tom.hawtin at oracle.com
Thu Jul 24 09:17:34 UTC 2014


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.

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

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

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

Tom



More information about the security-dev mailing list