JEP Review Request: Improve Security Manager Performance
David M. Lloyd
david.lloyd at redhat.com
Mon Jul 28 21:58:39 UTC 2014
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
More information about the security-dev
mailing list