JEP Review Request: Improve Security Manager Performance

[David M. Lloyd]

On 07/28/2014 03:33 PM, Peter Levart wrote:
>
> On 07/28/2014 03:34 PM, David M. Lloyd wrote:
>> On 07/24/2014 04:17 AM, Tom Hawtin wrote:
>>> 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.
>>
>> Logically speaking there is no weakness here though.
>>
>> In order to do privileged things (in static init), you must use a
>> privileged block.  You must always assume that the context is random
>> (because it is).  Thus static blocks are already using privileged blocks.
>
> But what to do if you don't want to do privileged things and play safe.
> Would following help?
>
> public class SomeClass {
>      static {
>          AccessController.doPrivileged(
>                  (PrivilegedAction<Void>) ::unprivilegedInit,
>                  new AccessControlContext(new ProtectionDomain[] { new
> ProtectionDomain(null, null) })
>          );
>      }
>
>      private static void unprivilegedInit() {
>          ...
>      }
>
> ...
>
>
> I guess the majority of static initializers don't do privileged things
> so they should not be privileged by default. I suspect it would be
> better for static initializers to behave like the above code - the
> contrary to what David would like them to be...

On the contrary, I think very many static initializers (most, if you're 
talking about frameworks and libraries only) are reading system 
properties, loading JNI libraries, performing I/O, accessing class 
loaders, or calling operations that do one of these things, causing an 
explosion of *Action classes and doPrivileged executions during class init.

Nevertheless, I'd rather at least see consistent behavior than the 
bucket of random we have today; if that means a minimal no-permission 
ACC is in effect, that's still an improvement in my book.  I would then 
go back to advocating some kind of compiler-enhanced way of lexically 
establishing permissions and privilege that does not entail object 
construction or lambda realization.

-- 
- DML