JEP Review Request: Improve Security Manager Performance

[Peter Firmstone]

No David is right, the code will run with the privileges of it's own ProtectionDomain, so if that PD is not trusted, the code cannot bypass security checks from static initializers.  This does not break secure by default.

A static initializer can write to static fields, but public or protected static mutable fields are a secuity risk, with or without a privileged call.

Because classes are loaded lazily by the jvm, the call stack context is randomised causing confusing and difficult to debug policy file configuration for administrators, often resulting in a relaxation of permissions beyond minimum privilege principles.

Making the suggested change actually improves security.

Regards,

Peter.


----- Original message -----
> On 07/23/2014 07:07 AM, Tom Hawtin wrote:
> > On 23/07/2014 05:26, David M. Lloyd wrote:
> > > I would suggest that one or more of the following be done to mitigate
> > > this problem:
> > > 
> > > • 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".   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.   It is very, very unusual for a static initializer to perform 
> any function which is practically exploitable; they are generally 
> stateless already, taking no input and producing no output.   I don't 
> think that it can be shown that the blanket ideology really provides any 
> measurable, real-world benefit; on the contrary, it causes real, 
> measurable detriment.   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".
> 
> Nevertheless, I never actually expected to convince anyone of this - 
> it's one of those ideas which seems culturally "against the grain", i.e. 
> the general principle tends to outweigh the practical reality.   Still, I 
> had to propose it, in order to be right with myself. :-)
> 
> > > • Allow static initialization blocks to partake in the aforementioned
> > > annotation-driven privileged method idea
> > 
> > Together with the last point, this does make the elevated privilege
> > contain a wider block of code than is necessary. This is [particularly
> > the case with static initialisers and initialisers where the code can
> > be spread throughout the class. OTOH, relevant sections of code could
> > be split out into small methods.
> 
> 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).
> 
> > > • Introduce a new permission checking mechanism which examines only a
> > > specific relevant caller's protection domain (perhaps determined by
> > > filter expression, possibly using the stack examination scheme that
> > > Mandy Chung has been working on)
> > 
> > Immediate caller checking, though has similarities to link-time access
> > checking, has a spectacularly unfortunate history.
> 
> That is an observation. :-)
> 
> > > • Introduce a programmatic "elevation" mechanism that increases the
> > > privileges of the currently executing method for the remainder of its
> > > execution without requiring a call-in to doPrivileged or
> > > instantiation of a privileged action object
> > 
> > Tom
> 
> -- 
> - DML

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