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
