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