Re: [PATCH] System Wide Capability Bounding Set

[Serge Hallyn]

Quoting Andrew G. Morgan (morgan@xxxxxxxxxx):
> > But how can that leave us with an impotent root?  Root would be easily
> > able to craft a file with any caps it wants in fI and fP on any of the
> > plethora of helper programs the kernel calls and escalate away it's
> > impotence.
> 
> Again, assuming that you are really trying to limit the power of
> kernel auto-exec'd programs, then you can see how secure bits can make
> root-power harder to obtain. (Examples using libcap utilities.)
> 
> [root@pip foo]# whoami
> root
> [root@pip foo]# ls -l foo.sh
> -rwx------ 1 bin nobody 31 2011-01-22 19:07 foo.sh
> [root@pip foo]# /sbin/capsh --secbits=0x0 -- ./foo.sh
> Hello, Root
> [root@pip foo]# /sbin/capsh --secbits=0x2f -- ./foo.sh
> /bin/bash: ./foo.sh: Permission denied
> [root@pip foo]#
> 
> That is, the 0x2f value of the secure bits turns off root's privilege.
> This includes the privilege to add capabilities to files (run this
> from the progs subdirectory of the libcap source, after a build):
> 
> [root@pip progs]# /sbin/capsh --secbits=0 -- \
> -c "/sbin/setcap cap_setfcap=ep setcap"
> [root@pip progs]# /sbin/getcap -v setcap
> setcap = cap_setfcap+ep
> [root@pip progs]# /sbin/setcap -r setcap
> [root@pip progs]# /sbin/getcap -v setcap
> setcap
> [root@pip progs]# /sbin/capsh --secbits=0x2f -- \
> -c "/sbin/setcap cap_setfcap=ep setcap"
> unable to set CAP_SETFCAP effective capability: Operation not permitted
> [root@pip progs]#
> 
> So, my point is that if the kernel threads were launched with a
> user-space configurable set of secure bits, and the regular exec()
> rules were used by these kernel-launched processes to obtain
> privilege, you could block the kernel from getting any user-space
> privileges via secure bits.

That's not even necessary, is it?  In order to get capabilities
from fI into pP, you need those capabilities in pI to begin
with.  So as long as we make sure that removing a capability from
the root task's bounding set also removes it from it's inheritable
set, no task it execs can re-gain those capabilities.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/