Authorization layer API and low level access checks.

[Peter Firmstone]

Hi Daniel,

That is the current intent, however identifying all methods which 
require protecting isn't a simple process and will change with each release.

The simplest part is determining whether the combination of User and 
domains calling have the necessary privileges (my current focus), the 
difficulty is in determining the methods that require protection for 
which Agents must be written.  It would be nice if OpenJDK could create 
check points through which security sensitive objects are passed and 
ensure these checkpoints are always used for passing references for 
those types of objects, so that any new JVM code also uses these 
methods, so that it would be easier to control and limit the number of 
locations for which we need to write agents, or other mechanisms, such 
as provider interfaces. Otherwise there is a lot of work involved in 
auditing every JVM release for new code, which has the potential to pass 
security sensitive object references.

It is not advisable to run untrusted code, the JDK doesn't adequately 
defend against untrusted code execution, eg memory consumption, throwing 
Errors, spawning Threads, the intent is to capture the privileged 
execution paths of software's intended functionality, using integration 
tests, recording and constraining the software by preventing other 
unintended privileged execution paths from being executed.

A use case for this is restricting (narrowing the audit scope) parsing 
of data to the combination of audited code in a server with 
authenticated client subjects.  The authenticated subject, represents 
the source of the data, so if there's no authenticated client subject, 
then we don't grant the privilege to avoid parsing of untrusted data, 
but in addition to that, we want to also constrain parsing to a 
particular domain / scope, which has been audited and approved for 
parsing authenticated user data.    While we trust other libraries 
utilised to generally do the right thing, it isn't practical to audit 
all code that might also be capable of parsing data that we don't intend 
to utilise, so we don't grant those libraries privileges they are not 
required to have, in accordance with principles of least privilege.

The intent is simply to limit scope to make security auditing practical 
and affordable.   Java has a very large ecosystem, so it isn't practical 
to audit everything.  We also want authorization to be simpler to deploy 
and less complex to utilize.

Regards,

Peter.

On 30/06/2021 4:42 am, Daniel Latrémolière wrote:
> Hello,
>
> Just for my knowledge, and if I understand your need to enforce a 
> security policy on code potentially untrusted.
>
> Isn't it possible to simply create a Java agent instrumenting bytecode 
> [1], which will replace [2] each Java method invocation, in untrusted 
> bytecode, which is returning a potentially sensitive object [3], by a 
> call to a generated adapter.
>
> In the generated adapter, you can add all useful code to validate if 
> corresponding code is allowed to see this object, potentially sensitive.
>
> A Java agent, would be compatible with all Java versions and I think 
> it would be possible to add exactly the permissions needed.
>
> Thanks,
>
> Daniel.
>
> [1]: 
> https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/ClassFileTransformer.html
>
> [2]: Bytecode transformation, by example with ASM: 
> https://stackoverflow.com/a/35635682
>
> [3]: By example, proxying each constructor or method returning an 
> instance of class like java.io.File and java.nio.file.Path (if you 
> want to do something like FilePermission).
>
>
>
> Le 29/06/2021 à 00:44, Peter Firmstone a écrit :
>> I'm currently playing around with a simpler security model, where one 
>> must escalate privileges with a privilegedCall, designed to be 
>> submitted to an Executor, which is task / thread confined.
>>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.