linux-kernel - Re: [RFC][PATCHSET] sanitized pathwalk machinery (v2)

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: <20200228030200.GH23230@ZenIV.linux.org.uk>
Date:   Fri, 28 Feb 2020 03:02:00 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Aleksa Sarai <cyphar@...har.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC][PATCHSET] sanitized pathwalk machinery (v2)

On Fri, Feb 28, 2020 at 12:24:51PM +1100, Aleksa Sarai wrote:

> > Another one is about LOOKUP_NO_XDEV again: suppose you have process'
> > root directly overmounted and cwd in the root of whatever's overmounting
> > it.  Resolution of .. will stay in cwd - we have no parent within the
> > chroot jail we are in, so we move to whatever's overmounting that root.
> > Which is the original location.  Should we fail on LOOKUP_NO_XDEV here?
> > Plain .. in the root of chroot jail (not overmounted by anything) does
> > *not*...
> 
> I think LOOKUP_NO_XDEV should block that since you end up crossing a
> mountpoint.

You are not.  Your process' root is overmounted and your current directory
is on that overmount.  You attempt to resolve ".." there.

# cd /
# unshare -m
# stat .
  File: .
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d      Inode: 2           Links: 25
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-26 20:51:06.623409892 -0500
Modify: 2020-02-26 20:43:51.284020000 -0500
Change: 2020-02-26 20:43:51.284020000 -0500
 Birth: -
# mkdir /tmp/foo
# mount -t tmpfs none /tmp/foo/
# for i in *; do test -d $i && mkdir /tmp/foo/$i && mount --rbind $i /tmp/foo/$i; done
# cd /tmp/foo/
# mount --move . /
# /bin/pwd
/
# ls
bin   dev  home  lib32  libx32      ltp    mnt  proc  run   srv  tmp  var
boot  etc  lib   lib64  lost+found  media  opt  root  sbin  sys  usr
# ls /
253_metadump  etc             lib32       media  run   usr
315.full      home            lib64       mnt    sbin  var
bin           initrd.img      libx32      opt    srv   vmlinuz
boot          initrd.img.old  lost+found  proc   sys   vmlinuz.old
dev           lib             ltp         root   tmp
# stat ..
  File: ..
  Size: 500             Blocks: 0          IO Block: 4096   directory
Device: 19h/25d Inode: 1875746     Links: 25
Access: (1777/drwxrwxrwt)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-27 21:48:45.649705410 -0500
Modify: 2020-02-27 21:46:40.829607188 -0500
Change: 2020-02-27 21:46:40.829607188 -0500
 Birth: -
# stat .
  File: .
  Size: 500             Blocks: 0          IO Block: 4096   directory
Device: 19h/25d Inode: 1875746     Links: 25
Access: (1777/drwxrwxrwt)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-02-27 21:48:45.649705410 -0500
Modify: 2020-02-27 21:46:40.829607188 -0500
Change: 2020-02-27 21:46:40.829607188 -0500
 Birth: -


See what's going on?  We have a tmpfs overmounting root; current directory
is the root of tmpfs; process root is on ext3.  Lookups for . and .. yield
exactly the same result here - we stay in the root of tmpfs.

Anyway, see #work.dotdot in vfs.git