[merged] Call setsid() before executing sandboxed code (CVE-2017-5226)

[smcv]

This prevents the sandboxed code from getting a controlling tty,
which in turn prevents it from accessing the TIOCSTI ioctl and hence
faking terminal input.

Fixes: #142

---

Note that this breaks shell job control:

user@host:~% ~/src/bubblewrap/bwrap --ro-bind / / --chdir / --dev /dev bash
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
user@host:~$ 

I think that's an acceptable sacrifice, but if you disagree, the other mechanism seen in setuid things seems to be non-trivial use of seccomp: util-linux/util-linux@8e49250

[rh-atomic-bot]

Can one of the admins verify this patch?
I understand the following commands:

• bot, add author to whitelist
• bot, test pull request
• bot, test pull request once

[rhatdan]

bot, add author to whitelist

[rhatdan]

bot, test pull request

[cgwalters]

Okay, so this affects pretty much every suid binary, and also those binaries for root to run to try to drop privileges. Basically any case where you have processes in different security domains connected to the same pty and same session. Fun. Really need some sort of "suid binary checklist".

As far as affecting functionality, one can restore job control by simply allocating a new pty - the sanity check I did was to run tmux in bwrap with this patch, which worked fine. The root cause is we're inheriting FDs to the pty outside of the namespace.

We could just tweak the demo shell script to allocate a pty I'd say.

[cgwalters]

Hmm, so the kernel code does:

        if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
                return -EPERM;

But is it possible for us to regain a reference to the controlling tty somehow? I tried just open(/proc/self/fd/0) and that just got EACCES, but didn't debug it further.

[cgwalters]

I got curious as to - why does that call to setsid() exist in util-linux? Took a bit of annotate digging through renames and such, but it leads to:

util-linux/util-linux@c6a1746 ➡️
https://bugzilla.redhat.com/show_bug.cgi?id=173008

So, this type of thing has been around a long time but not widely socialized I guess.

[cgwalters]

I think I'd like to do the seccomp fix in addition at some point, but this looks good. Thanks!

@rh-atomic-bot r+ 3f2f885

[rh-atomic-bot]

⌛ Testing commit 3f2f885 with merge d7fc532...

[rh-atomic-bot]

☀️ Test successful - status-redhatci
Approved by: cgwalters
Pushing d7fc532 to master...

[smcv]

But is it possible for us to regain a reference to the controlling tty somehow?

tty_ioctl(4) says no, unless the shell into which the attacker is trying to feed malicious input relinquishes its controlling terminal:

       TIOCSCTTY int arg
              Make  the given terminal the controlling terminal of the calling
              process.  The calling process must be a session leader  and  not
              have  a controlling terminal already.  For this case, arg should
              be specified as zero.

              If this terminal is already the controlling terminal of  a  dif‐
              ferent  session  group,  then the ioctl fails with EPERM, unless
              the caller has the CAP_SYS_ADMIN capability and arg equals 1, in
              which case the terminal is stolen, and all processes that had it
              as controlling terminal lose it.

[alexlarsson]

This isn't a great fix because it pretty much breaks using bwrap to create an interactive shell
For instance, if you run bwrap --bind / / sh, and then press ctrl-Zthen the "outer" shell gets unfrozen, but the "inner" shell doesn't get frozen, and both try to read terminal input at the same time.

[cgwalters]

Let's track regressions/issues from this via new issues?