newrole not working when built with LSPP_PRIV=y

newrole not working when built with LSPP_PRIV=y

[Laurent Bigonville]

Hi,

Running newrole executable compiled with LSPP_PRIV=y I get the following
error while it's trying to switch role:

Error sending audit message.

It seems that the CAP_AUDIT_WRITE capability is not set [0]. Adding this
capability to the list doesn't seems enough, I then get the following error:

failed to exec shell: Operation not permitted

Looking at the fedora tree, I've found this patch[1] (which is not
merged upstream) that seems to fix both issues.

The patch seems to break an other thing, it Fedora the newrole
executable is not setuid root, but it is granted a bunch of capabilities
explicitly, if I setuid this executable instead of granting these
capabilities, I get yet an other error:

Sorry, newrole failed to drop capabilities: Operation not permitted

So I guess something need to be fixed here.

Cheers,

Laurent Bigonville

[0]
https://github.com/SELinuxProject/selinux/blob/master/policycoreutils/newrole/newrole.c#L590

[1]
https://github.com/fedora-selinux/selinux/commit/339a6fed0b37f8b82e4382bc6a5c9367119ed92b

Re: newrole not working when built with LSPP_PRIV=y

[Stephen Smalley]

On 09/26/2015 09:10 PM, Laurent Bigonville wrote:
> Hi,
>
> Running newrole executable compiled with LSPP_PRIV=y I get the following
> error while it's trying to switch role:
>
> Error sending audit message.
>
> It seems that the CAP_AUDIT_WRITE capability is not set [0]. Adding this
> capability to the list doesn't seems enough, I then get the following error:
>
> failed to exec shell: Operation not permitted
>
> Looking at the fedora tree, I've found this patch[1] (which is not
> merged upstream) that seems to fix both issues.
>
> The patch seems to break an other thing, it Fedora the newrole
> executable is not setuid root, but it is granted a bunch of capabilities
> explicitly, if I setuid this executable instead of granting these
> capabilities, I get yet an other error:
>
> Sorry, newrole failed to drop capabilities: Operation not permitted
>
> So I guess something need to be fixed here.

Yes, the current code just seems to be wrong here.  The setresuid() call 
will drop all capabilities if newrole is setuid-root and the caller is 
non-root, so it will end up dropping all capabilities immediately.  Then 
the attempt to further set the capabilities will fail (as above), as 
will any subsequent privileged operations.  As currently written, this 
can only work if not setuid-root and using file-caps.  And in that case, 
the setresuid() call doesn't make sense.

Dan?

>
> Cheers,
>
> Laurent Bigonville
>
> [0]
> https://github.com/SELinuxProject/selinux/blob/master/policycoreutils/newrole/newrole.c#L590
>
> [1]
> https://github.com/fedora-selinux/selinux/commit/339a6fed0b37f8b82e4382bc6a5c9367119ed92b

Re: newrole not working when built with LSPP_PRIV=y

[Laurent Bigonville]

Le 29/09/15 21:35, Stephen Smalley a écrit :
> On 09/26/2015 09:10 PM, Laurent Bigonville wrote:
>> [...]
>>
>> The patch seems to break an other thing, it Fedora the newrole
>> executable is not setuid root, but it is granted a bunch of capabilities
>> explicitly, if I setuid this executable instead of granting these
>> capabilities, I get yet an other error:
>>
>> Sorry, newrole failed to drop capabilities: Operation not permitted
>>
>> So I guess something need to be fixed here.
>
> Yes, the current code just seems to be wrong here.  The setresuid() 
> call will drop all capabilities if newrole is setuid-root and the 
> caller is non-root, so it will end up dropping all capabilities 
> immediately.  Then the attempt to further set the capabilities will 
> fail (as above), as will any subsequent privileged operations.  As 
> currently written, this can only work if not setuid-root and using 
> file-caps.  And in that case, the setresuid() call doesn't make sense.
>
> Dan?

Apparently libcapng has a capng_change_id(3) function that can be used 
to "change the credentials retaining capabilities".

Laurent Bigonville

Re: newrole not working when built with LSPP_PRIV=y

[Stephen Smalley]

On 10/01/2015 03:51 AM, Laurent Bigonville wrote:
>
>
> Le 29/09/15 21:35, Stephen Smalley a écrit :
>> On 09/26/2015 09:10 PM, Laurent Bigonville wrote:
>>> [...]
>>>
>>> The patch seems to break an other thing, it Fedora the newrole
>>> executable is not setuid root, but it is granted a bunch of capabilities
>>> explicitly, if I setuid this executable instead of granting these
>>> capabilities, I get yet an other error:
>>>
>>> Sorry, newrole failed to drop capabilities: Operation not permitted
>>>
>>> So I guess something need to be fixed here.
>>
>> Yes, the current code just seems to be wrong here.  The setresuid()
>> call will drop all capabilities if newrole is setuid-root and the
>> caller is non-root, so it will end up dropping all capabilities
>> immediately.  Then the attempt to further set the capabilities will
>> fail (as above), as will any subsequent privileged operations.  As
>> currently written, this can only work if not setuid-root and using
>> file-caps.  And in that case, the setresuid() call doesn't make sense.
>>
>> Dan?
>
> Apparently libcapng has a capng_change_id(3) function that can be used
> to "change the credentials retaining capabilities".

If you just delete the setresuid() call entirely from the 
NAMESPACE_PRIV=y drop_capabilities() function, then it works (on top of 
the Fedora patch you cited).  That function wasn't supposed to be doing 
setresuid() in the first place; that is deferred to 
transition_to_caller_uid(), _after_ pam_namespace has run.  I'm guessing 
that pam_namespace is broken in Fedora.

Note that the Fedora patch you cited has at least one bug; it reverts an 
upstream fix to open stdin read/write to avoid breaking programs like 
tmux that assume that if stdin is a tty, then it can be both read and 
written.