From: "Mickaël Salaün" <mic@digikod.net> To: "Eric W. Biederman" <ebiederm@xmission.com>, Al Viro <viro@ZenIV.linux.org.uk>, David Drysdale <drysdale@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Jann Horn <jannh@google.com>, Linux API <linux-api@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-security-module <linux-security-module@vger.kernel.org>, Kees Cook <keescook@chromium.org> Subject: Re: new ...at() flag: AT_NO_JUMPS Date: Mon, 8 May 2017 21:34:09 +0200 [thread overview] Message-ID: <2e28bd2d-44df-6850-c60d-1a12c584e632@digikod.net> (raw) In-Reply-To: <8737cj6oao.fsf@xmission.com> [-- Attachment #1.1: Type: text/plain, Size: 3359 bytes --] On 05/05/2017 22:28, Eric W. Biederman wrote: > Al Viro <viro@ZenIV.linux.org.uk> writes: > >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn <jannh@google.com> wrote: >>>> >>>> Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >>>> pointing to /srv/www/example.org/foo; the path given to the syscall is >>>> "bar/../../../../etc/passwd". The path walk enters the "bar" directory. >>>> Thread 2 moves /srv/www/example.org/foo/bar to >>>> /srv/www/example.org/bar. >>>> Thread 1 processes the rest of the path ("../../../../etc/passwd"), never >>>> hitting /srv/www/example.org/foo in the process. >>>> >>>> I'm not really familiar with the VFS internals, but from a coarse look >>>> at the patch, it seems like it wouldn't block this? >>> >>> I think you're right. >>> >>> I guess it would be safe for the RCU case due to the sequence number >>> check, but not the non-RCU case. >> >> Yes and no... FWIW, to exclude that it would suffice to have >> mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first. >> Then this kind of race will end up with -ENOENT due to path_connected() >> logics in follow_dotdot_rcu()/follow_dotdot(). I'm not sure about the >> intended applications, though - is that thing supposed to be used along with >> some horror like seccomp, or...? > > As I recall the general idea is that if you have an application like a > tftp server or a web server that gets a path from a possibly dubious > source. Instead of implementing an error prone validation logic in > userspace you can use AT_BENEATH and be certain the path resolution > stays in bounds. > > As you can do stronger things as root this seems mostly targeted at > non-root applications. > > I seem to recall part of the idea was to sometimes pair this to seccomp > to be certain your application can't escape a sandbox. That plays to > seccomp limitations that it can inspect flags as they reside in > registers but seccomp can't follow pointers. Here is the code and tests from David Drysdale: https://github.com/google/capsicum-linux/commits/openat-v2 ...and the latest patch: https://lkml.org/lkml/2015/3/9/407 The O_BENEATH flag have also been discussed for FreeBSD to support Capsicum. > > Which all suggests that we would want something similar to is_subdir > when AT_BENEATH is specified that we check every time we follow .. > that would verify that on the same filesystem we stay below and > that we also stay on a mount that is below. mount --move has > all of the same challenges for enforcing you stay within bounds > as rename does. FYI, I'm working on a new LSM [1] to work around the limitations of seccomp-bpf, especially the pointer checks. The idea is to enable some filtering as seccomp-bpf can do but instead of checking at the syscall level, Landlock take advantage of LSM hooks. I had a first PoC of an eBPF function and map type to check if a file was beneath another [2]. I plan to create a new one that record a "snapshot" of the current mount tree into an eBPF map to be able to check if a file is beneath or a parent of another one. [1] https://lkml.kernel.org/r/20170328234650.19695-1-mic@digikod.net [2] https://lkml.kernel.org/r/20161026065654.19166-9-mic@digikod.net [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Mickaël Salaün" <mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org> To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>, Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>, David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-fsdevel <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-security-module <linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> Subject: Re: new ...at() flag: AT_NO_JUMPS Date: Mon, 8 May 2017 21:34:09 +0200 [thread overview] Message-ID: <2e28bd2d-44df-6850-c60d-1a12c584e632@digikod.net> (raw) In-Reply-To: <8737cj6oao.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> [-- Attachment #1.1: Type: text/plain, Size: 3475 bytes --] On 05/05/2017 22:28, Eric W. Biederman wrote: > Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org> writes: > >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote: >>>> >>>> Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >>>> pointing to /srv/www/example.org/foo; the path given to the syscall is >>>> "bar/../../../../etc/passwd". The path walk enters the "bar" directory. >>>> Thread 2 moves /srv/www/example.org/foo/bar to >>>> /srv/www/example.org/bar. >>>> Thread 1 processes the rest of the path ("../../../../etc/passwd"), never >>>> hitting /srv/www/example.org/foo in the process. >>>> >>>> I'm not really familiar with the VFS internals, but from a coarse look >>>> at the patch, it seems like it wouldn't block this? >>> >>> I think you're right. >>> >>> I guess it would be safe for the RCU case due to the sequence number >>> check, but not the non-RCU case. >> >> Yes and no... FWIW, to exclude that it would suffice to have >> mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first. >> Then this kind of race will end up with -ENOENT due to path_connected() >> logics in follow_dotdot_rcu()/follow_dotdot(). I'm not sure about the >> intended applications, though - is that thing supposed to be used along with >> some horror like seccomp, or...? > > As I recall the general idea is that if you have an application like a > tftp server or a web server that gets a path from a possibly dubious > source. Instead of implementing an error prone validation logic in > userspace you can use AT_BENEATH and be certain the path resolution > stays in bounds. > > As you can do stronger things as root this seems mostly targeted at > non-root applications. > > I seem to recall part of the idea was to sometimes pair this to seccomp > to be certain your application can't escape a sandbox. That plays to > seccomp limitations that it can inspect flags as they reside in > registers but seccomp can't follow pointers. Here is the code and tests from David Drysdale: https://github.com/google/capsicum-linux/commits/openat-v2 ...and the latest patch: https://lkml.org/lkml/2015/3/9/407 The O_BENEATH flag have also been discussed for FreeBSD to support Capsicum. > > Which all suggests that we would want something similar to is_subdir > when AT_BENEATH is specified that we check every time we follow .. > that would verify that on the same filesystem we stay below and > that we also stay on a mount that is below. mount --move has > all of the same challenges for enforcing you stay within bounds > as rename does. FYI, I'm working on a new LSM [1] to work around the limitations of seccomp-bpf, especially the pointer checks. The idea is to enable some filtering as seccomp-bpf can do but instead of checking at the syscall level, Landlock take advantage of LSM hooks. I had a first PoC of an eBPF function and map type to check if a file was beneath another [2]. I plan to create a new one that record a "snapshot" of the current mount tree into an eBPF map to be able to check if a file is beneath or a parent of another one. [1] https://lkml.kernel.org/r/20170328234650.19695-1-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org [2] https://lkml.kernel.org/r/20161026065654.19166-9-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2017-05-08 19:34 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-29 22:04 new ...at() flag: AT_NO_JUMPS Al Viro 2017-04-29 22:04 ` Al Viro 2017-04-29 23:17 ` Andy Lutomirski 2017-04-29 23:17 ` Andy Lutomirski 2017-04-29 23:25 ` Al Viro 2017-04-29 23:25 ` Al Viro 2017-04-30 1:13 ` Andy Lutomirski 2017-04-30 4:38 ` Matthew Wilcox 2017-04-30 4:38 ` Matthew Wilcox 2017-04-30 16:10 ` Al Viro 2017-04-30 16:10 ` Al Viro 2017-05-01 4:52 ` Andy Lutomirski 2017-05-01 5:15 ` Al Viro 2017-05-01 5:15 ` Al Viro 2017-05-01 17:36 ` Jann Horn 2017-05-01 19:37 ` Andy Lutomirski 2017-05-05 0:30 ` Al Viro 2017-05-05 0:30 ` Al Viro 2017-05-05 0:44 ` Andy Lutomirski 2017-05-05 1:06 ` Al Viro 2017-05-05 1:27 ` Linus Torvalds 2017-05-05 1:27 ` Linus Torvalds 2017-05-05 3:00 ` Al Viro 2017-05-05 3:00 ` Al Viro 2017-05-05 4:01 ` Linus Torvalds 2017-05-05 4:31 ` Andy Lutomirski 2017-05-05 2:47 ` Jann Horn 2017-05-05 3:46 ` Linus Torvalds 2017-05-05 4:39 ` Al Viro 2017-05-05 4:39 ` Al Viro 2017-05-05 4:44 ` Andy Lutomirski 2017-05-05 20:04 ` Eric W. Biederman 2017-05-05 20:04 ` Eric W. Biederman 2017-05-05 20:28 ` Eric W. Biederman 2017-05-08 19:34 ` Mickaël Salaün [this message] 2017-05-08 19:34 ` Mickaël Salaün 2017-05-18 8:50 ` David Drysdale 2017-09-10 20:26 Jürg Billeter
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=2e28bd2d-44df-6850-c60d-1a12c584e632@digikod.net \ --to=mic@digikod.net \ --cc=drysdale@google.com \ --cc=ebiederm@xmission.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=viro@ZenIV.linux.org.uk \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.