[ 
https://issues.apache.org/jira/browse/STORM-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855712#comment-15855712
 ] 

Tibor Kiss commented on STORM-2348:
-----------------------------------

Created a 
[PoC|https://github.com/tibkiss/storm/commit/c6d57c0d389b57a7d77180f444ea52a7c1a7b5b8]
 of this approach.

Unfortunately theory and practice collides:
{code}
tiborkiss@eiger ~/w/s/s/t/n/worker-launcher ❯❯❯ ls -l worker-launcher
-rwxrwx---. 1 root tiborkiss 58442 Feb  7 05:15 worker-launcher
tiborkiss@eiger ~/w/s/s/t/n/worker-launcher ❯❯❯ getcap worker-launcher
worker-launcher = cap_setuid+ep
tiborkiss@eiger ~/w/s/s/t/n/worker-launcher ❯❯❯ ./worker-launcher --checksetup
Error resolving the canonical name for the executable : Permission 
denied!Invalid permissions on worker-launcher binary.
tiborkiss@eiger ~/w/s/s/t/n/worker-launcher ❯❯❯ echo $?                         
                                                                                
                                                                                
                                                                                
                                          ⏎
22
{code}

The above sample shows that {{setuid()}} was successful, but {{realpath()}} on 
the worker-launcher fails.

> setuid(0) & setgid call results are not checked in worker-launcher
> ------------------------------------------------------------------
>
>                 Key: STORM-2348
>                 URL: https://issues.apache.org/jira/browse/STORM-2348
>             Project: Apache Storm
>          Issue Type: Improvement
>          Components: storm-core
>            Reporter: Tibor Kiss
>            Assignee: Tibor Kiss
>
> worker-launcher elevates it's privileges using {{setuid(0)}} and 
> {{setgid(group_info->gr_gid)}} calls:
> https://github.com/apache/storm/blob/master/storm-core/src/native/worker-launcher/impl/main.c#L116-L119
> The current implementation does not validate the return value of those calls, 
> rather it checks' the privileges (setuid + root ownership) of the binary 
> through {{check_executor_binary()}}
> This approach works correctly, but it could be improved: 
> If we'd check the return values of setuid(0) & setgid() and drop the binary 
> check it would be possible to gain elevated privileges using CAP_SETUID & 
> CAP_SETGID. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to