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