...

Motivation

...

To protect crucial system resources, we should use the Java Sandbox [1].

The Sandbox is composed of the next elements:

...

That is the basis to implement the integration of the Java Sandbox with AIApache Ignite.

The main unit of the Ignite Sandbox is the IgniteSandbox interface, accessed through IgniteSecurity.
Users for this interface are components that can run a user-defined code. To run a user-defined code with restrictions,
they have to pass it to one of the IgniteSandbox.execute methods method.

There are two a few conditions to run user-defined code with restrictions:

• installed GridSecurityProcessor;
• GridSecurityProcessor#sandboxEnabled == true;
• installed SecurityManager.

...

1. Get sandbox permissions from a SecuritySubject of the current SecurityContext.
2. Create AccessControlContext with IgniteDomainCombiner that constructed using permissions from step 1.
3. Call AccessController.doPrivileged with passed a user-defined code and AccessControlContext from step 2.

IgniteDomainCombiner is responsible for updating the Protection Domains with permissions of the current SecuritySubject.

...

A user-defined code should have the opportunity of using the public API of Ignite on a remote node.
But he may don't have some permissions to execute this operation successfully. For example, to put a value into a cache,
it requires permissions for accessing to reflection API and reading system property IGNITE_ALLOW_ATOMIC_OPS_IN_TX.
In that case, we have to use AccessController.doPrirvelged without AccessControlContext call to exclude a user-defined code from checking of permissions.Utils SecurityUtils.doPriveleged method does calling AccessController.doPrirvelged a more convenient way

We can achieve that behavior by using a proxy of interface Ignite that executes methods inside a privileged block. Builder methods of Ignite proxy create a proxy of public interfaces (IgniteCache, IgniteCompute, and so on) that run their methods inside a privileged block too.
Additionally, using of Ignite proxy allows restricting access of a user-defined code to internal Ignite classes.

Phase 1.

1. Create implementations of the IgniteSandbox interface.
2. Extend interface IgniteSecurity to use IgniteSandbox.
3. Extend interface SecuritySubject to get sandbox permissions.The default implementation of this method should return ALL_PERMISSIONS, which means - no restrictions.
   That is essential for backward compatibility with existing implementations of GridSecurityProcessor.
4. Execution a user-defined code in the Ignite Sandbox for the following components:
   a. ComputeJob;
   b. EntryProcessor;
   c. IgniteBiPredicate;
   d. IgniteClosure;
   e. StreamReceiver.

...

1. Restrict access a user-defined code to internal API of Ignite:
   a. Restrict internal package access;
   b. Encapsulation of IgniteKernal.
2. Execution a user-defined code in the Ignite Sandbox for the following features:
   a. Continuous Queries;
   b. IgniteMassaging;
   c. ServiceGridIgniteEvents.

Risks and Assumptions

The existing implementations of interfaces Runnable, IgniteRunnable,
Callable.class, IgniteCallable, ComputeTask, ComputeJob, IgniteClosure, IgniteBiClosure, IgniteDataStreamer, IgnitePredicate,
IgniteBiPredicate cannot cast the instance of Ignite to IgniteEx or IgniteKernal if the Sandbox is enabled.// 

Discussion Links

http://apache-ignite-developers.2346864.n4.nabble.com/Review-needed-for-IGNITE-11410-Sandbox-for-user-defined-code-td43955.html

...

...