Fallout from dlopen() blocking SIGSYS

[Christian Brauner]

On Wed, Dec 18, 2019 at 07:14:45PM -0700, Jed Davis wrote:
> 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

It does to some extent. As I mentioned, you can continue syscalls from
the notifier. So you can - beware of races with other threads - rewrite
the syscall arguments to what you want. You'd intercept clone3(), look
at the memory arguments and either deny, or rewrite the syscall args and
continue the task.

> 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

Apart from the generic "it used to have bugs" what is your main worry
here and why are you not using namespaces to _limit_ attack surface?
There's quite a few things you can do just in terms of creating user
namespaces, dropping capabilities, coming up with very limited and
targeted id mappings (340 mappings per userns can be specified
nowadays) etc. pp.

> 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

You can limit the number of user namespaces by writing
echo 10 > /proc/sys/user/max_user_namespaces since v4.9.
Setting it to 10 will mean you can only create 10 user namespaces
globally iirc.
It's similar for all other namespaces.

> 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.

I've mentioned in the previous message that I intend to work on this.
How urgent is this aka when would you want something for this? The
approach Kees and I settled one was to do this in a per-system call
basis for now.

Christian