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.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
