linux-kernel - Re: [PATCH v2 1/3] namei: implement O_BENEATH-style AT

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: <20181027014114.GA52393@freebsd.org>
Date:   Sat, 27 Oct 2018 01:41:14 +0000
From:   Ed Maste <emaste@...ebsd.org>
To:     cyphar@...har.com, David Drysdale <drysdale@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] namei: implement O_BENEATH-style AT_* flags

On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai <cyphar@...har.com> wrote:
>
> +#ifndef O_BENEATH
> +#define O_BENEATH      00040000000 /* *Not* the same as capsicum's O_BENEATH! */
> +#endif

I had originally followed up privately to Aleksa about this comment (to
suggest that it's outdated and should be removed), but the reference
Capsicum implementation now supports O_BENEATH and I think it's sensible to
follow up here with the additional context.

O_BENEATH originally came from the Capsicum Linux port, and inherited the
restriction against ".." path components from years ago when the port was
done.  In addition, FreeBSD did not originally implement O_BENEATH as the
"beneath" behaviour is inherently provided once a process enters a
capability mode sandbox.  However, Capsicum now allows ".." paths, and
FreeBSD supports O_BENEATH separately from capability mode.  Absolute paths
are not yet allowed with O_BENEATH but a change is in review to permit them.

On FreeBSD a lookup prevented by O_BENEATH semantics returns ENOTCAPABLE,
the errno coming from the Capsicum implementation.

Ideally I would like to see us have the same API; none of this work has yet
shipped in a FreeBSD release and there is an opportunity for us to make
changes to match the interface and errors Linux may adopt.