[ https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690583#comment-17690583 ]
Mikhail Petrov commented on IGNITE-15322: ----------------------------------------- [~av] Thank you a lot for the review! > 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: 2h 20m > 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. > The first two steps give us the ability to > A. safely skip authorization of SYSTEM tasks which are > called through INTERNAL API. > 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. > 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) > Example of SYSTEM public tasks - Visor tasks on which the user control script > is implemented > They 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 PublicAwareJob 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| > By the way the SecurityAwareJob interface, implemented by all Visor jobs, > allows you to specify for each specific Visor job what permissions it > requires. Also it is proposed to guard all Visor Jobs with ADMIN_OPS > permission by default. > 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 code is wrapped and executed via special SYSTEM > tasks. As a result all DotNet runnable/callable/tasks are authorized by the > name of the SYSTEM wrapper task. So if TASK_EXECUTE permissions for the > SYSTEM wrapper task is granted - user can execute whathever DotNet custom tas > he wants. After the propsed changes SYTEM task authorization will no more.be > performed. So DotNet custom code execution will become completeley > unauthorised. We should fix it in a separate ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)