Fallout from dlopen() blocking SIGSYS

[Jed Davis]

On Wed, Dec 18, 2019 at 9:26 AM Florian Weimer <fweimer@redhat.com> wrote:
> I hope that these new seccomp interfaces are available on those systems
> which benefit of them most (where applications or glibc would use
> clone3, for example).

clone3 is going to be a problem with seccomp regardless, and as far as
I know there's nothing concretely planned for the kernel that will
help.  If the caller can fall back to regular clone(), the seccomp
policy can make it fail with ENOSYS via SECCOMP_RET_ERRNO, which
doesn't care about signal state.  If signals aren't blocked *and* the
clone3 call is in the subset supported by clone(), then a SIGSYS trap
could theoretically rewrite it, but we've already established that
signals may be blocked so that doesn't matter.  SECCOMP_RET_USER_NOTIF
doesn't appear to allow anything useful here, since there's no “inject
thread into other process” operation as far as I know.  (Maybe if the
supervisor could attach with ptrace and force the supervisee into a
clone() syscall… but that still doesn't help if it's a call that
actually needs clone3.)

As far as reasons to filter clone3: requiring CLONE_THREAD is slightly
important, because our seccomp-bpf policy allows tgkill (and
rt_tgsigqueueinfo) with tgid == the process's pid, so if the process
could fork and wait for its old pid to be recycled… this is relatively
minor but it is something that can be prevented when using the old
clone.  (Containing the process in its own pid namespace would prevent
that, but we don't currently require access to namespace creation as
Chrome does.)  There's also the general problem of attack surface
reduction; CLONE_NEWUSER is probably the biggest risk, but in our use
cases if the distribution allows it for unprivileged processes then
we'll use it to call chroot, which prevents any further use of
CLONE_NEWUSER (and, by extension, gaining capabilities to use other
namespace-related flags like CLONE_NEWNET).  So that's not the end of
the world, but it's not ideal, and I don't think the Chromium security
people would like it either.

To summarize, if in the future pthread_create could use clone3 with no
fallback, then there are going to be minor but fundamental problems
with sandboxing and we'd need the kernel to provide some first-class
way to handle memory parameters.  There was a high-level proposal at
[1], but there were concerns about the design raised in followup
messages, and as far as I know nothing at the level of a prototype or
a concrete plan.

--Jed

[1]: https://lore.kernel.org/ksummit-discuss/CALCETrVpbSDraiwJRmOj28wepTjEPiSDQz=DUuSig_P1rSGZ6Q@mail.gmail.com/