Re: [lmi] Missing system directories in chroot [Was: Creating a chroot for cross-building lmi]

[Greg Chicares]

On 2016-09-16 20:52, Vadim Zeitlin wrote:
> On Fri, 16 Sep 2016 20:39:11 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I'm willing to accept that what I observed is impossible as long as
> GC> 'schroot' is free of defects. But it is not--it "is using the host's
> GC> filesystem to resolve symlinks in the chroot":
> 
>  I am not sure if it's worth delving into these bug reports, but, at the
> risk of seeming stubborn,

I'll run the same risk myself, because I'm learning plenty from this
discussion.

> I don't think any defect with symlinks in schroot
> could allow code running inside a chroot to escape from it -- this would
> only be possible due to a (horrible) bug in the kernel and I definitely
> haven't heard about anything like this.

I think you're saying that once chroot(2), i.e.
  int chroot(const char *path);
has been called, the kernel enforces isolation. Okay. But it doesn't
enforce a chroot's isolation before chroot(2) is called: we might say that
the chroot doesn't even exist before then, so there's nothing to isolate.

I'm suggesting that schroot works like this:
  run setup scripts
  mount filesystems [introduce defects at this stage]
  ...
  call chroot(2) [isolation occurs at this precise instant]
  ...
  umount filesystems upon exit
and that the problem occurs in one of those early steps--inside schroot,
before it calls chroot(2):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096#34
|
| It is simply calling realpath(3) on the mount destination in the chroot,
| from a process that is not chrooted, so realpath(3) is going to use the
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| host filesystem to resolve symlinks such as
| '/<chroot>/dev/shm -> /run/shm'. It then tries to fixup the final
| resolved path but appended the chroot basepath but it's too late at that
| point, the host's filesystem has already been used to resolve the
| symlink target.

The issue I reported earlier was (commands in chronological order):

  [host]$ ls -l /dev/sh*
  lrwxrwxrwx 1 root root 8 Feb 16  2016 /dev/shm -> /run/shm

  [chroot]$ sudo rm /dev/shm

  [host]$ ls -l /dev/sh*
  zsh: no matches found: /dev/sh*

Isn't that perfectly consistent with the portion of debian bug 728096
quoted above...and also with our strong belief that the kernel would
prevent this except in "a process that is not chrooted"?

Or are you saying that the last sentence quoted from the bug report
above, viz.

| ... It then tries to fixup the final
| resolved path but appended the chroot basepath but it's too late at that
| point, the host's filesystem has already been used to resolve the
| symlink target.

must be false in principle--i.e., that there's no plausible way for
a (defective) schroot script to pass the host's /run/shm into the
chroot it's creating?