linux-kernel - Re: [PATCH v3] capabilities.7, prctl.2: Document ambient capabilities

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: <CALCETrXLDA3bPtZJjCa0P61jwZLYVzS5axfMRW82Yu-w1avPsw@mail.gmail.com>
Date:	Fri, 4 Dec 2015 08:12:53 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Andy Lutomirski <luto@...nel.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Andrew Morton <akpm@...uxfoundation.org>,
	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	"Ted Ts'o" <tytso@....edu>, "Andrew G. Morgan" <morgan@...nel.org>,
	Linux API <linux-api@...r.kernel.org>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	Aaron Jones <aaronmdjones@...il.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Markku Savela <msa@...h.iki.fi>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v3] capabilities.7, prctl.2: Document ambient capabilities

On Fri, Dec 4, 2015 at 7:08 AM, Michael Kerrisk (man-pages)
<mtk.manpages@...il.com> 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.

>
> ===
>
> 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.

--Andy

>
> ===
>
> I did quite a bit of tweaking of the text that you added for
> the capabilities page. Could you please check the following
> to make sure I added no errors:
>
>        Ambient (since Linux 4.3):
>               This  is a set of capabilities that are preserved across
>               an execve(2) of a program that is not  privileged.   The
>               ambient capability set obeys the invariant that no capa‐
>               bility can ever be ambient if it is not  both  permitted
>               and inheritable.
>
>               The  ambient  capability  set  can  be directly modified
>               using prctl(2).  Ambient capabilities are  automatically
>               lowered  if  either  of  the  corresponding permitted or
>               inheritable capabilities is lowered.
>
>               Executing a program that changes UID or GID due  to  the
>               set-user-ID  or set-group-ID bits or executing a program
>               that has any file capabilities set will clear the  ambi‐
>               ent  set.  Ambient capabilities are added to the permit‐
>               ted set and assigned to the effective set when execve(2)
>               is called.

Looks good (other than the preexisting gotcha above).

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