Scoped Values and better security

[Volker Simonis]

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