Scoped Values and better security

[Robert Engels]

I would expect scoped variables to work similar to thread locals otherwise the entire Java permissioning/sandbox won’t work. It relies on the thread local for a security context to know what can be executed. Many frameworks use a similar contact to hold the logged in user in web apps, etc. 

> On Apr 27, 2023, at 9:18 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I take this discussion from the JEP issue in JBS [1] to the mailing
> list as requested by Alan:
> 
> My initial comment was:
> 
> In your motivation section you say:
> 
>  Normally, data is shared between caller and callee by passing it as
> method arguments,
>  but this is not viable for a Principal shared between the server
> component and the data
>  access component because the server component calls untrusted user
> code first. We need
>  a better way to share data from the server component to the data
> access component than
>  wiring it into a cascade of untrusted method invocations.
> 
> I can't see how ThreadLocals or ScopedValues improve the situation
> here with respect to "untrusted code"? I fully agree that passing the
> Principal data from the server component down to the data access
> component by means of method parameters is ugly and disturbing. But I
> can't see how it should be more "unsecure", because the "untrusted
> user code" can access a potential Principle object from its argument
> list in much the same way like a ThreadLocale or ScopedValue defined
> in an enclosing scope.
> 
> So maybe it would be better to focus more on the usability aspect than
> on "avoiding information exposure to untrusted code" in the Motivation
> section?
> 
> Andrew's response was:
> 
>> But I can't see how it should be more "unsecure", because the "untrusted user code" can access a potential Principle object from its argument list in much the same way like a ThreadLocale or ScopedValue defined in an enclosing scope.
> 
> I don't understand what you don't understand.
> 
> We can reason about code when we know that its access to data is
> constrained in some way. We know that scoped values have particular
> properties, in that we can restrict accesses to them to code we trust.
> This isn't specifically security related: '"trusted code" can mean
> simply code that we've verified, and therefore can trust. If we set a
> scoped value in an outer scope, call via some unknown code, then
> access that scoped value in an inner scope, we know for certain that
> its value is one we set in the outer scope. The (untrusted, unknown)
> code in between can't have substituted something else.
> 
> And Alan added:
> 
> It may be that Volker has missed the point that the capability, as in
> the ThreadLocal or ScopeLocal variable, is usually stored in a private
> static final so it's not accessible to code in the intermediate frames
> between where it is set and (usually) the callback that will read the
> value. It would probably be better to bring questions to loom-dev
> rather having a protracted discussion in comments here.
> 
> So finally my new comment:
> 
> In your example "Web framework example with scoped values" both, the
> `Server` class where the ScopedValue `PRINCIPAL` is declared with
> `package-private` visibility as well as the `DBAccess` class which
> uses the `PRINCIPAL` are in the default unnamed package. But I doubt
> that in a real world application the server class and the database
> access class will be in the same package. So if you'd declare
> `PRINCIPAL` in a private field as Alan suggested, it would be
> impossible for another component to access it. If on the other hand
> your scoped value was declared in a public field, any untrusted,
> intermediate code executed between outer and inner scope could access
> it just as well.
> 
> @Andrew: the untrusted, intermediate code can both read and even
> rebind the value of the ScopedValue set in an outer scope. The
> "security" you are talking about is a feature of the Java access rules
> and not of the scoped value implementation. I don't see how in a real
> world (e.g. Spring) application, the web server, the DB engine and the
> logging framework can easily share access to a common scoped value
> without exposing this scoped value to intermediate code outside of
> these components as well.
> 
> But maybe I'm missing something in which case it might sense to
> explain this a little more detailed in the JEP?
> 
> Thank you and best regards,
> Volker
> 
> [1] https://bugs.openjdk.org/browse/JDK-8304357