[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions

["Mikhail Petrov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Petrov updated IGNITE-15322:
------------------------------------
    Description: 
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
 - the task started implicitly (under the hood), customer should not to know about it.
 - this is a system task (not defined by a customer), the tasks needs for a normal grid workflow.

Also, I suppose there are any other implicitly tasks, which could lead to unexpected behavior (need permissions).

Proposed way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the Ignite codebase) or USER.

Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite Sanbox implementation.

2. Add mechanism to detect if task execution was initiated by the user (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the public and private Compute APIs. 
Task executioin requests received through Ignite Thin Clients are considered PUBLIC CALLs. 
For Ignite node API we can provide dedicated methods to obtain internal version of compute instances in IgniteEx and force developers to use them for any internal means.
{code:java}
public interface IgniteEx extends Ignite {
    /** */
    public IgniteCompute internalCompute();

    /** */
    public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to 
A. safely skip authorization of SYSTEM tasks which are 
called through INTERNAL API unless permissions are specified explicitly (see clause 3).
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means that all user task execution requests received through REST or Thin client protocols MUST be executed through PUBLIC API).

3. Add the ability to explicitly specify for SYSTEM task/callable/runnable/closure what permission should be checked before its execution. This helps to skip sending task execution requests between nodes if the user does not have permission to execute the task.

It can be solved by introducing optionsl interface that compute job can implement.
{code:java}
/** */
public interface SecurityAwareJob {
     /** */
    public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories - 
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC tasks (tasks that are part oof the ignite code but are available to the user and can be executed through the PUBLIC API)

Examples of SYSTEM public tasks -
 - Visor tasks on which the user control script is implemented
 - JDBC tasks
All of them are executed through Thin Client which is considered Public API.

Considering that SYSTEM PUBLIC tasks can potentially be executed by the user, we must force the developer to explicitly specify permissions for tasks of this type. It can be done by checking that SYSTEM tasks that are executed through PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|restricted|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly specified permissions|

5. Authorization of SYSTEM tasks cancellation must be skipped it they are canceled by the same user who started them, oterwise dedicated permissions is required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.

Possible troubles:

1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module. If some tasks are defined inside other Ignite modules - they will not be considered SYSTEM. Currently there are no such task.

2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper task. We should decide how to properly fix their authorization.

3. We must decide what permissions are required for Visor tasks.

  was:
For example, this code needs TASK_EXECUTE permissions.
{code:java}
Affinity affinity = ignite.affinity("TEST");
affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
This is unexpected behavior, because:
 - the task started implicitly (under the hood), customer should not to know about it.
 - this is a system task (not defined by a customer), the tasks needs for a normal grid workflow.

Also, I suppose there are any other implicitly tasks, which could lead to unexpected behavior (need permissions).

Possible way to solve this issue:
1. Add mechanism to destinguish whether task class is SYSTEM (part of the Ignite codebase) or USER.

Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite Sanbox implementation.

2. Add mechanism to detect if task execution was initiated by the user (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
It seems that the easiest way to achieve this is to completely separate the public and private Compute APIs. 
Task executioin requests received through Ignite Thin Clients are considered PUBLIC CALLs. 
For Ignite node API we can provide dedicated methods to obtain internal version of compute instances in IgniteEx and force developers to use them for any internal means.
{code:java}
public interface IgniteEx extends Ignite {
    /** */
    public IgniteCompute internalCompute();

    /** */
    public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to 
A. safely skip authorization of SYSTEM tasks which are 
called through INTERNAL API unless permissions are specified explicitly (see clause 3).
B. keep authorization of PUBLIC tasks intact
C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means that all user task execution requests received through REST or Thin client protocols MUST be executed through PUBLIC API).

3. Add the ability to explicitly specify for SYSTEM task/callable/runnable/closure what permission should be checked before its execution. This helps to skip sending task execution requests between nodes if the user does not have permission to execute the task.

It can be solved by introducing optionsl interface that compute job can implement.
{code:java}
/** */
public interface SecurityAwareJob {
     /** */
    public SecurityPermissionSet requiredPermissions();
}
{code}
4. SYSTEM tasks can splitted into two categories - 
SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC tasks (tasks that are part oof the ignite code but are available to the user and can be executed through the PUBLIC API)

Examples of SYSTEM public tasks -
 - Visor tasks on which the user control script is implemented
 - JDBC tasks
All of them are executed through Thin Client which is considered Public API.

Considering that SYSTEM PUBLIC tasks can potentially be executed by the user, we must force the developer to explicitly specify permissions for tasks of this type. It can be done by checking that SYSTEM tasks that are executed through PUBLIC API impelements SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|restricted|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly specified permissions|

5. Authorization of SYSTEM tasks cancellation must be skipped it they are canceled by the same user who started them, oterwise dedicated permissions is required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.

Possible troubles:

1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module. If some tasks are defined inside other Ignite modules - they will not be considered SYSTEM. Currently there are no such task.

2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper task. We should decide how to properly fix their authorization.

3. We must decide what permissions are required for Visor tasks.


> System tasks should run without any explicitly granted permissions
> ------------------------------------------------------------------
>
>                 Key: IGNITE-15322
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15322
>             Project: Ignite
>          Issue Type: Bug
>          Components: compute, security
>            Reporter: Ilya Kazakov
>            Assignee: Mikhail Petrov
>            Priority: Minor
>              Labels: ise
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> For example, this code needs TASK_EXECUTE permissions.
> {code:java}
> Affinity affinity = ignite.affinity("TEST");
> affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
> This is unexpected behavior, because:
>  - the task started implicitly (under the hood), customer should not to know about it.
>  - this is a system task (not defined by a customer), the tasks needs for a normal grid workflow.
> Also, I suppose there are any other implicitly tasks, which could lead to unexpected behavior (need permissions).
> Proposed way to solve this issue:
> 1. Add mechanism to destinguish whether task class is SYSTEM (part of the Ignite codebase) or USER.
> Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite Sanbox implementation.
> 2. Add mechanism to detect if task execution was initiated by the user (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
> It seems that the easiest way to achieve this is to completely separate the public and private Compute APIs. 
> Task executioin requests received through Ignite Thin Clients are considered PUBLIC CALLs. 
> For Ignite node API we can provide dedicated methods to obtain internal version of compute instances in IgniteEx and force developers to use them for any internal means.
> {code:java}
> public interface IgniteEx extends Ignite {
>     /** */
>     public IgniteCompute internalCompute();
>     /** */
>     public IgniteCompute internalCompute(ClusterGroup grp);
> }
> {code}
> The first two steps give us the ability to 
> A. safely skip authorization of SYSTEM tasks which are 
> called through INTERNAL API unless permissions are specified explicitly (see clause 3).
> B. keep authorization of PUBLIC tasks intact
> C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it means that all user task execution requests received through REST or Thin client protocols MUST be executed through PUBLIC API).
> 3. Add the ability to explicitly specify for SYSTEM task/callable/runnable/closure what permission should be checked before its execution. This helps to skip sending task execution requests between nodes if the user does not have permission to execute the task.
> It can be solved by introducing optionsl interface that compute job can implement.
> {code:java}
> /** */
> public interface SecurityAwareJob {
>      /** */
>     public SecurityPermissionSet requiredPermissions();
> }
> {code}
> 4. SYSTEM tasks can splitted into two categories - 
> SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC tasks (tasks that are part oof the ignite code but are available to the user and can be executed through the PUBLIC API)
> Examples of SYSTEM public tasks -
>  - Visor tasks on which the user control script is implemented
>  - JDBC tasks
> All of them are executed through Thin Client which is considered Public API.
> Considering that SYSTEM PUBLIC tasks can potentially be executed by the user, we must force the developer to explicitly specify permissions for tasks of this type. It can be done by checking that SYSTEM tasks that are executed through PUBLIC API impelements SecurityPermissionAware interface described above.
> ||X||Public API||Private API||
> |PUBLIC task|auth by task name|restricted|
> |SYSTEM INTERNAL task|restricted|auth skipped|
> |SYSTEM PUBLIC task|auth by explicitly specified permissions|auth by explicitly specified permissions|
> 5. Authorization of SYSTEM tasks cancellation must be skipped it they are canceled by the same user who started them, oterwise dedicated permissions is required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their names.
> Possible troubles:
> 1. Mentioned SecurityUtils#isSystemType works only for the ignite-core module. If some tasks are defined inside other Ignite modules - they will not be considered SYSTEM. Currently there are no such task.
> 2. Currently all DotNet tasks are authorized by the name of the SYSTEM wrapper task. We should decide how to properly fix their authorization.
> 3. We must decide what permissions are required for Visor tasks.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)