Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1633356 > unrolled thread

new ...at() flag: AT_NO_JUMPS

Started byAl Viro <viro@ZenIV.linux.org.uk>
First post2017-04-30 00:10 +0200
Last post2017-05-08 21:40 +0200
Articles 4 on this page of 24 — 7 participants

Back to article view | Back to linux.kernel

Contents

  new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-04-30 00:10 +0200
    Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-04-30 01:20 +0200
      Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-04-30 01:30 +0200
        Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-04-30 03:20 +0200
        Re: new ...at() flag: AT_NO_JUMPS Matthew Wilcox <willy@infradead.org> - 2017-04-30 06:40 +0200
          Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-04-30 18:20 +0200
            Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-01 07:00 +0200
              Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-01 07:20 +0200
    Re: new ...at() flag: AT_NO_JUMPS Jann Horn <jannh@google.com> - 2017-05-01 19:40 +0200
      Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-01 21:40 +0200
      Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 02:40 +0200
        Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-05 02:50 +0200
          Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 03:10 +0200
        Re: new ...at() flag: AT_NO_JUMPS Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-05 03:30 +0200
          Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 05:10 +0200
            Re: new ...at() flag: AT_NO_JUMPS Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-05 06:10 +0200
              Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-05 06:40 +0200
        Re: new ...at() flag: AT_NO_JUMPS Jann Horn <jannh@google.com> - 2017-05-05 04:50 +0200
          Re: new ...at() flag: AT_NO_JUMPS Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-05 05:50 +0200
            Re: new ...at() flag: AT_NO_JUMPS Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-05 06:40 +0200
              Re: new ...at() flag: AT_NO_JUMPS Andy Lutomirski <luto@kernel.org> - 2017-05-05 06:50 +0200
                Re: new ...at() flag: AT_NO_JUMPS ebiederm@xmission.com (Eric W. Biederman) - 2017-05-05 22:20 +0200
              Re: new ...at() flag: AT_NO_JUMPS ebiederm@xmission.com (Eric W. Biederman) - 2017-05-05 22:40 +0200
                Re: new ...at() flag: AT_NO_JUMPS Mickaël Salaün <mic@digikod.net> - 2017-05-08 21:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1636158

FromAndy Lutomirski <luto@kernel.org>
Date2017-05-05 06:50 +0200
Message-ID<tDDlL-5hC-1@gated-at.bofh.it>
In reply to#1636157
On Thu, May 4, 2017 at 9:39 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> 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...?

How hard would it be for the kernel to prevent this on its own?
Asking users to do the mount --rbind seems like it's asking for users
to forget to do it.

[toc] | [prev] | [next] | [standalone]

#1636713

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-05-05 22:20 +0200
Message-ID<tDRRM-6Av-27@gated-at.bofh.it>
In reply to#1636158
Andy Lutomirski <luto@kernel.org> writes:

> On Thu, May 4, 2017 at 9:39 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> 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...?
>
> How hard would it be for the kernel to prevent this on its own?
> Asking users to do the mount --rbind seems like it's asking for users
> to forget to do it.

The logic of path_connected checks every time you follow .. if the
parent directory you find is below your starting directory.
Mostly path_connected is optimized by noticing non-bind mounts
and doing nothing.  In this case we would need the is_subdir check
every time we follow ..

So it might just be cheaper not to follow ..

Which leads to something else we need to be careful with.

Suppose for whatever insane reason . is on a directory that has
another directory mounted on top.  Then following "some_dir/.."
would result in a different directory than we were on.

Eric

[toc] | [prev] | [next] | [standalone]

#1636722

Fromebiederm@xmission.com (Eric W. Biederman)
Date2017-05-05 22:40 +0200
Message-ID<tDSb8-6HT-9@gated-at.bofh.it>
In reply to#1636157
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.

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.

Eric

[toc] | [prev] | [next] | [standalone]

#1637674

FromMickaël Salaün <mic@digikod.net>
Date2017-05-08 21:40 +0200
Message-ID<tEWFH-87A-19@gated-at.bofh.it>
In reply to#1636722

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web