Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752646AbbLKTSO (ORCPT ); Fri, 11 Dec 2015 14:18:14 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:35488 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751562AbbLKTSL (ORCPT ); Fri, 11 Dec 2015 14:18:11 -0500 Message-ID: <566B216F.6060501@gmail.com> Date: Fri, 11 Dec 2015 20:18:07 +0100 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Lutomirski CC: mtk.manpages@gmail.com, Andy Lutomirski , Serge Hallyn , Andrew Morton , Jarkko Sakkinen , "Ted Ts'o" , "Andrew G. Morgan" , Linux API , Mimi Zohar , Austin S Hemmelgarn , linux-security-module , Aaron Jones , Serge Hallyn , LKML , Markku Savela , Jonathan Corbet Subject: Re: [PATCH v3] capabilities.7, prctl.2: Document ambient capabilities References: <3721cd96525af4cb0a671e9a36ac6402c8e5379a.1446594067.git.luto@kernel.org> <5661AC50.3070300@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3533 Lines: 101 On 12/04/2015 05:12 PM, Andy Lutomirski wrote: > On Fri, Dec 4, 2015 at 7:08 AM, Michael Kerrisk (man-pages) > wrote: >> Hi Andy, >> >> I have applied your patch (below). Thanks for writing it. >> But I have a question or two and a request. >> >> === >> >> In the capabilities(7) page tehre is the longstanding text: >> >> An application can use the following call to lock itself, and >> all of its descendants, into an environment where the only way >> of gaining capabilities is by executing a program with associā€ >> ated file capabilities: >> >> prctl(PR_SET_SECUREBITS, >> SECBIT_KEEP_CAPS_LOCKED | >> SECBIT_NO_SETUID_FIXUP | >> SECBIT_NO_SETUID_FIXUP_LOCKED | >> SECBIT_NOROOT | >> SECBIT_NOROOT_LOCKED); >> >> As far as I can estimate, no changes are needed here to include >> SECBIT_NO_CAP_AMBIENT_RAISE and SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED >> in the above prctl() call, but could you confirm please? > > Correct. I'll probably write up a patch to suggest that doing this is > a poor idea on a conventional distro, though, and I'll explain why. I > suppose than deleting this would be an option, too. Ping! :-) >> === >> >> In the message for kernel commit >> 58319057b7847667f0c9585b9de0e8932b0fdb08 >> you included this text: >> >> [[ >> Because capability inheritance is so >> broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and >> then calling execve effectively drops capabilities. Therefore, >> setresuid from root to nonroot conditionally clears pA unless >> SECBIT_NO_SETUID_FIXUP is set. Processes that don't like this can >> re-add bits to pA afterwards. >> ]] >> >> I'm struggling to understand the significance of this text, >> especially as your man-pages patch makes no mention of this point. >> >> The thing is, that text ("Therefore...") implies that there's >> something special going on beyond the rules already documented >> elsewhere. I mean, according to the rules aly documented elsewhere >> in the page: > > Whoops, I forgot to add that to the manpage. > >> >> (1) If a process with UIDs of 0 sets all its UIDs >> nonzero, then, the permitted and effective sets are cleared >> (that's the classical behavior), and because the permitted >> set is cleared, then so is the ambient set. >> >> (2) And if we set SECBIT_NO_SETUID_FIXUP then >> a UID 0 ==> nonzero transition doesn't clear permitted and >> effective sets, and then of course the ambient set is not >> cleared. >> >> So, what additional point were you meaning to convey in >> the commit message? (Maybe it was just cruft in the commit >> message, but if not, can you explain precisely the arguments >> for setresuid() that are supposed to generate the special >> behavior described by the above text.) > > It's case (1b), which is like (1) but with KEEPCAPS set. The > permitted set doesn't get cleared, but the ambient set is still > cleared. > > I'll write a manpage patch. Ping :-) (Make these separate patches please.) Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/