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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 26 Jan 2011 18:34:14 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Serge Hallyn <serge.hallyn@...onical.com>
Cc:	"Andrew G. Morgan" <morgan@...nel.org>,
	"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

Let me reboot the conversation just a little.  My goal is to be able to
drop capabilities from a system such that they can never come back.  The
two capabilities I am most interested in are CAP_SYS_MODULE and
CAP_SYS_RAWIO.  I want to boot a machine in a manor I control, drop
those caps, and then give root to an entity that I do not trust.  At the
moment it is impossible to do this.  Absolutely impossible.  It is
impossible because the earliest I can drop capabilities is
in /sbin/init.  Lets assume I patch /sbin/init to drop those two caps
from the bset, pE, pI, and pP.  One might think they are gone for good,
but they aren't.

The way that kernel helper programs get exec'ed is that a task or maybe
an async event causes the kernel to queue some information on a list.
That information is removed from the list by a special kthread and a
userspace program is exec'ed.  The exec rules are going to apply to the
capability sets associated with the kthread.  Those are compiled into
the kernel.  I need a way to prevent capabilities from coming back.

I proposed a global bset (much like we used to have, but without the
ability for init to add stuff back) and was shot down.

Andrew original proposed a prctl() which would cause the exec call to
not automatically add capabilities to pE and would rely on filecaps.  I
claim this is not reasonable since root is going to have control of the
fcaps.  All that would be needed for root to regain either cap is to
change the helper program to be an sshd server and add back these 2
dropped caps in fcaps.

At this point it seems to me like what I must do is add a way for a task
with enough priv to force caps out of the bset and pI of the kthread
which upcalls to run userspace programs.  Thus when the kthread runs a
program it cannot give those privs....

Does this seem reasonable?  What would such an interface look like?
(This is scarily like the old meaning of CAP_SETPCAP....)

--
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/