linux-kernel - Re: [PATCH] System Wide Capability Bounding Set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Jan 2011 15:40:18 -0600
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	Eric Paris <eparis@...hat.com>,
	"Serge E. Hallyn" <serge@...onical.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, sgrubb@...hat.com
Subject: Re: [PATCH] System Wide Capability Bounding Set

Quoting Andrew G. Morgan (morgan@...nel.org):
> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/