From: Aleksa Sarai <email@example.com> To: Andy Lutomirski <firstname.lastname@example.org> Cc: Al Viro <email@example.com>, Jeff Layton <firstname.lastname@example.org>, "J. Bruce Fields" <email@example.com>, Arnd Bergmann <firstname.lastname@example.org>, David Howells <email@example.com>, Eric Biederman <firstname.lastname@example.org>, Jann Horn <email@example.com>, Christian Brauner <firstname.lastname@example.org>, David Drysdale <email@example.com>, Tycho Andersen <firstname.lastname@example.org>, Kees Cook <email@example.com>, Linux Containers <firstname.lastname@example.org>, Linux FS Devel <email@example.com>, Linux API <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Alexei Starovoitov <firstname.lastname@example.org>, Chanho Min <email@example.com>, Oleg Nesterov <firstname.lastname@example.org>, Aleksa Sarai <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, LKML <email@example.com>, linux-arch <firstname.lastname@example.org> Subject: Re: [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution Date: Tue, 26 Mar 2019 00:04:29 +1100 [thread overview] Message-ID: <20190325130429.dbrgjxnvq3w5cpb3@yavin> (raw) In-Reply-To: <CALCETrV-Q4qZXGeavBPQbF6-VVz7hqvjRkbhFeYmbGiQgu5Omg@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2976 bytes --] On 2019-03-21, Andy Lutomirski <email@example.com> wrote: > On Wed, Mar 20, 2019 at 7:38 AM Aleksa Sarai <firstname.lastname@example.org> wrote: > > Now that the holiday break is over, it's time to re-send this patch > > series (with a few additions, due to new information we got from > > CVE-2019-5736 -- which this patchset mostly protected against but had > > some holes with regards to #!-style scripts). > > I generally like this, but, as Linus pointed out, it will be > unfortunate if application authors see this as just another > non-portable weird Linux API and don't use it. Would it be worthwhile > to put some thought into making it an API that other OSes might be > willing to implement? As it stands, the openat(2) flags are getting > rather crazy in this patch set. > > Aleksa had a resolveat(2) proposal that really didn't seem too bad. I agree having a bunch of O_* flags for resolution feels quite ugly (and crazy) -- but the last time I pitched resolveat(2) the reaction was lukewarm to say the least. It's basically an O_PATHv2 and I don't know how popular that suggestion might be. I wouldn't mind pitching it again though (now that I have a better idea of how to handle some of the UX worries I had). But, if we have a resolveat(2) we'll need to add O_EMPTYPATH support for openat(2) so that you can open scoped paths without using the /proc/self/fd/$n trick. However, you run into reopening permission issues (as we saw in CVE-2019-5736 and countless other CVEs). There might be a solution for this which Andy and I have talked about off-list. There is also the problem of the execveat(2) attack -- which is dealt with in patch 5 of this series. In order to scope #!-script resolution we need to have AT_* flags for the same resolution restriction (defeating the point of a resolveat(2) slightly). There is an argument that we shouldn't need AT_THIS_ROOT or AT_BENEATH support (because ideally you should be doing execve(2) in a pivot_root anyway) but AT_NO_MAGICLINKS is pretty important -- since it allows you to block the circumvention mm->dumpable in certain situations (as we saw in CVE-2019-5736). The solution Andy and I have discussed is a way to make fd-reopening (a seemingly little-known trick outside of container runtimes) much safer such that we don't need mitigations like AT_NO_MAGICLINKS on execveat(2). If we assume that idea works out (I'm still trying to get a working patch for that idea) then resolveat(2) would be sufficient and we don't need AT_* flags on execveat(2). tl;dr: I think resolveat(2) is much nicer, and assuming it's not an unpopular idea I think we should go for it. But there are several other threads of discussion that we might want to have first (such as how to improve the fd-reopening design so it's safer before we expose it to everyone). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-03-25 13:05 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-20 14:37 Aleksa Sarai 2019-03-20 14:37 ` [PATCH RESEND v5 1/5] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai 2019-03-20 14:37 ` [PATCH RESEND v5 2/5] namei: O_BENEATH-style path resolution flags Aleksa Sarai 2019-03-20 14:37 ` [PATCH RESEND v5 3/5] namei: O_THISROOT: chroot-like path resolution Aleksa Sarai 2019-03-20 14:37 ` [PATCH RESEND v5 4/5] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai 2019-03-20 14:37 ` [PATCH RESEND v5 5/5] binfmt_*: scope path resolution of interpreters Aleksa Sarai 2019-03-21 17:06 ` [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution Andy Lutomirski 2019-03-25 13:04 ` Aleksa Sarai [this message] 2019-04-23 20:13 ` Kees Cook 2019-04-23 20:24 ` Christian Brauner 2019-04-24 15:38 ` Aleksa Sarai 2019-04-25 13:22 ` Adam Borowski 2019-04-25 19:45 ` Aleksa Sarai -- strict thread matches above, loose matches on Subject: below -- 2019-03-06 19:12 Aleksa Sarai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190325130429.dbrgjxnvq3w5cpb3@yavin \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).