Scoped Values and better security

[Alan Bateman]

Just re-found this mail.

Yes, I think there is merit to have the JEP include advice on treating 
the ScopedValue as a capability and restricting the accessibility of the 
ScopedValue field as much as possible. As I think you understand, a 
scoped value works like a implicit parameter and you need the "key" to 
read it, it's no different to ThreadLocal except that the ScopedValue is 
only set to a value for the bounded execution of a method.

I also agree that the example of DBAccess access the PRINCIPAL field in 
Server isn't great and replacing it with an example that uses a callback 
might be better example to teach how to use this API.

-Alan

On 27/04/2023 15:17, Volker Simonis 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