linux-kernel - Re: [RFC] Capabilities still can't be inherited by normal programs

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]

Message-ID: <CALCETrXyX2aYjbLRCpzp-h_CXBb=K7OWkO1b+tVTRz9LQQOzdQ@mail.gmail.com>
Date:	Sun, 2 Dec 2012 10:35:13 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...hat.com>,
	"Serge E. Hallyn" <serge@...onical.com>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs

On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan <morgan@...nel.org> wrote:
> There is a fairly well written paper ;-) explaining how things are
> supposed to work:
>
>   http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf
>
> The inheritable set is not intended to work the way you seem to want.
> Naive inheritance like that is quite explicitly the opposite of what
> was designed.

I'm aware that the system was designed, or perhaps evolved, to prevent
users with uid != 0 from inheriting capabilities unless vfs
inheritable caps are granted on a per-file basis.  I want a way around
that -- I want to mix non-root, capabilities, and exec.  This is damn
near impossible right now if I don't have CAP_SETFCAP or root's
explicit, per-program cooperation.  CAP_SETFCAP is essentially
equivalent to "let me do anything".

As it stands, using something like pam_cap to grant a user cap_net_raw
is useless -- that user can't use the privilege because (unless uid ==
0) the privilege will never end up in the permitted set.

I want to come up with a way to change this that will, convincingly,
not open up any new security holes.  The current concept of process
inheritable capabilities seems so vague and so oddly defined that I'm
not sure I want to touch it.  In an ideal world, I'd want pI <= pP and
fP <= fI to be invariants, and I'd like programs without vfs caps set
to have fI = <everything>.  Making this change will surely break
something, though.

I'm looking for ideas.

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