From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756226AbdEHTec (ORCPT ); Mon, 8 May 2017 15:34:32 -0400 Received: from smtp-sh2.infomaniak.ch ([128.65.195.6]:56525 "EHLO smtp-sh2.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754306AbdEHTe3 (ORCPT ); Mon, 8 May 2017 15:34:29 -0400 From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Subject: Re: new ...at() flag: AT_NO_JUMPS To: "Eric W. Biederman" , Al Viro , David Drysdale References: <20170429220414.GT29622@ZenIV.linux.org.uk> <20170505003030.GM29622@ZenIV.linux.org.uk> <20170505043902.GP29622@ZenIV.linux.org.uk> <8737cj6oao.fsf@xmission.com> Cc: Linus Torvalds , Jann Horn , Linux API , Linux Kernel Mailing List , linux-fsdevel , linux-security-module , Kees Cook Message-ID: <2e28bd2d-44df-6850-c60d-1a12c584e632@digikod.net> Date: Mon, 8 May 2017 21:34:09 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <8737cj6oao.fsf@xmission.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0sQ5G4r9pjcmEm5QKrfQDh7tq3NqEIvlF" X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0sQ5G4r9pjcmEm5QKrfQDh7tq3NqEIvlF Content-Type: multipart/mixed; boundary="lJB5a0mC6OQv6KTrqnm4bRnsAsH1vFUGq"; protected-headers="v1" From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= To: "Eric W. Biederman" , Al Viro , David Drysdale Cc: Linus Torvalds , Jann Horn , Linux API , Linux Kernel Mailing List , linux-fsdevel , linux-security-module , Kees Cook Message-ID: <2e28bd2d-44df-6850-c60d-1a12c584e632@digikod.net> Subject: Re: new ...at() flag: AT_NO_JUMPS References: <20170429220414.GT29622@ZenIV.linux.org.uk> <20170505003030.GM29622@ZenIV.linux.org.uk> <20170505043902.GP29622@ZenIV.linux.org.uk> <8737cj6oao.fsf@xmission.com> In-Reply-To: <8737cj6oao.fsf@xmission.com> --lJB5a0mC6OQv6KTrqnm4bRnsAsH1vFUGq Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 05/05/2017 22:28, Eric W. Biederman wrote: > Al Viro writes: >=20 >> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn 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" directo= ry. >>>> 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 lo= ok >>>> 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 f= irst. >> 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 alon= g with >> some horror like seccomp, or...? >=20 > 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. >=20 > As you can do stronger things as root this seems mostly targeted at > non-root applications. >=20 > 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 =2E..and the latest patch: https://lkml.org/lkml/2015/3/9/407 The O_BENEATH flag have also been discussed for FreeBSD to support Capsic= um. >=20 > 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 --lJB5a0mC6OQv6KTrqnm4bRnsAsH1vFUGq-- --0sQ5G4r9pjcmEm5QKrfQDh7tq3NqEIvlF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEUysCyY8er9Axt7hqIt7+33O9apUFAlkQyDEACgkQIt7+33O9 apUWuwf/dH3Nt64NdSigHvcO2rNo8nNVqkyltiaVkMWHwS6b4KLOi35hKTpgRBNO bWwuf485qifebr3L2b8cas3aTEvp96O2UUpFcYWYVvTYjGlfM//Eh/BkSEdoYGLQ 9vfFuyVnKd2o6mdb/zsRfSVjG4yE9WclIGWusPFbjCSXXvAUuqLF6HjQi+Q6wBs5 ZQeJvtaYJHVUhpp98ToPk3SIWa110jffBZ8ABIM4W2MJ5DYYOfxrNDk7//yxFPsq ur0e/E0hJhnhMWvhcwRmdmxI/fpCUG8nHU/FAEni2foveHlRRhRN/ROtd6t0RZ50 XYxse4MPF7mZHvNXsJqusSCq1lZbwQ== =FNYV -----END PGP SIGNATURE----- --0sQ5G4r9pjcmEm5QKrfQDh7tq3NqEIvlF--