From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 588F0C433E3 for ; Fri, 24 Jul 2020 00:13:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32DE020888 for ; Fri, 24 Jul 2020 00:13:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="l8gmwJum" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728320AbgGXANu (ORCPT ); Thu, 23 Jul 2020 20:13:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728319AbgGXANt (ORCPT ); Thu, 23 Jul 2020 20:13:49 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6D95C0619E2 for ; Thu, 23 Jul 2020 17:13:48 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id r4so3781981wrx.9 for ; Thu, 23 Jul 2020 17:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u6x/hJOAHY4ipAqr2hJOXVMYMMf3KgJBBZ1yOdjcCvI=; b=l8gmwJumnfBAOwcf7hDnzKOckke+7FJJ1NS9zYl0CO+6Pru0aHNLw4HL2QDUsBgdhH axu8m6MrxU5VdYN4oAGIZdtsMVu8j6flA574tZoNh4po7WcTh6q1rieHBqKlRltKdbCD mRmuZwZL83CaZlupM/YSFfxgvx1txVJARFTLHaQrldSKkiDAJ/spYh49b9M+3RwKvWub /2DNZhf6sGQMubLVZWjTR5dSCHcOiP8VDJL948DebpH1wfKg/YflimMDf8rSPcikR7M9 4/pQ1OEAAbhLbUCW9li1IIdxp2v+wVu52E/H3p9jXWs7jm42G4MKPbBYCWb276JbC5f9 XzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u6x/hJOAHY4ipAqr2hJOXVMYMMf3KgJBBZ1yOdjcCvI=; b=KCEC3ofeT9TncKuAH3W0hgHnpodc8x6LqX2OnkquZDtPXOYrN4Rcpv8PyL20Y5QEnd rnoSXnzHyGCNbckH6Sq62Wxau+6vzDBikNmLLmzUGRyGi/m9dKtqLyYDDXTkjDTuFOc1 aFdHSO/ioHCVL/T0jyipbJhOEZaLx4ZIgXCWdv1Z/MblNDknBsWHjFETU2g4f9YXQ+Iz FER5KJ+e70eRrM/tXfFwyvAxF30ExTBsP/sXVEcTlRVj4qKTsZfw9BiqRA5ie8DmUdAO GJWipmcYAS6yMuwi/g1/pcEaJD8KTm49bX52zCJqDPAbYdF+dBh1XrTxXyp61CfAx88s kLcg== X-Gm-Message-State: AOAM533zfLYm8+r88nLvMgzpwEf6kWmoVLxdxpMiEydNcUWuEuM0B+9w JjYJQS7JXZqXU1UK4rvwdVvJ799zFEJXv8v8Mx1HXg== X-Google-Smtp-Source: ABdhPJxL5Y1BrfDtq2upmNHI5yCi1q/zfAI4WwmzzlYEyc+rDsh6CrhBn6+3cgw1FRPldkigKYwPi5ct9CVXTswVgMc= X-Received: by 2002:a5d:65cd:: with SMTP id e13mr6637550wrw.213.1595549625931; Thu, 23 Jul 2020 17:13:45 -0700 (PDT) MIME-Version: 1.0 References: <20200423002632.224776-1-dancol@google.com> <20200423002632.224776-3-dancol@google.com> <20200508125054-mutt-send-email-mst@kernel.org> <20200508125314-mutt-send-email-mst@kernel.org> <20200520045938.GC26186@redhat.com> <202005200921.2BD5A0ADD@keescook> <20200520194804.GJ26186@redhat.com> <20200520195134.GK26186@redhat.com> <20200520211634.GL26186@redhat.com> In-Reply-To: From: Nick Kralevich Date: Thu, 23 Jul 2020 17:13:28 -0700 Message-ID: Subject: Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only To: Lokesh Gidra Cc: Jeffrey Vander Stoep , Andrea Arcangeli , Suren Baghdasaryan , Kees Cook , "Michael S. Tsirkin" , Daniel Colascione , Jonathan Corbet , Alexander Viro , Luis Chamberlain , Iurii Zaikin , Mauro Carvalho Chehab , Andrew Morton , Andy Shevchenko , Vlastimil Babka , Mel Gorman , Sebastian Andrzej Siewior , Peter Xu , Mike Rapoport , Jerome Glisse , Shaohua Li , linux-doc@vger.kernel.org, LKML , Linux FS Devel , Tim Murray , Minchan Kim , Sandeep Patil , kernel@android.com, Daniel Colascione , Kalesh Singh Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Thu, Jul 23, 2020 at 10:30 AM Lokesh Gidra wrote: > From the discussion so far it seems that there is a consensus that > patch 1/2 in this series should be upstreamed in any case. Is there > anything that is pending on that patch? That's my reading of this thread too. > > > Unless I'm mistaken that you can already enforce bit 1 of the second > > > parameter of the userfaultfd syscall to be set with seccomp-bpf, this > > > would be more a question to the Android userland team. > > > > > > The question would be: does it ever happen that a seccomp filter isn't > > > already applied to unprivileged software running without > > > SYS_CAP_PTRACE capability? > > > > Yes. > > > > Android uses selinux as our primary sandboxing mechanism. We do use > > seccomp on a few processes, but we have found that it has a > > surprisingly high performance cost [1] on arm64 devices so turning it > > on system wide is not a good option. > > > > [1] https://lore.kernel.org/linux-security-module/202006011116.3F7109A@keescook/T/#m82ace19539ac595682affabdf652c0ffa5d27dad As Jeff mentioned, seccomp is used strategically on Android, but is not applied to all processes. It's too expensive and impractical when simpler implementations (such as this sysctl) can exist. It's also significantly simpler to test a sysctl value for correctness as opposed to a seccomp filter. > > > > > > > > > If answer is "no" the behavior of the new sysctl in patch 2/2 (in > > > subject) should be enforceable with minor changes to the BPF > > > assembly. Otherwise it'd require more changes. It would be good to understand what these changes are. > > > Why exactly is it preferable to enlarge the surface of attack of the > > > kernel and take the risk there is a real bug in userfaultfd code (not > > > just a facilitation of exploiting some other kernel bug) that leads to > > > a privilege escalation, when you still break 99% of userfaultfd users, > > > if you set with option "2"? I can see your point if you think about the feature as a whole. However, distributions (such as Android) have specialized knowledge of their security environments, and may not want to support the typical usages of userfaultfd. For such distributions, providing a mechanism to prevent userfaultfd from being useful as an exploit primitive, while still allowing the very limited use of userfaultfd for userspace faults only, is desirable. Distributions shouldn't be forced into supporting 100% of the use cases envisioned by userfaultfd when their needs may be more specialized, and this sysctl knob empowers distributions to make this choice for themselves. > > > Is the system owner really going to purely run on his systems CRIU > > > postcopy live migration (which already runs with CAP_SYS_PTRACE) and > > > nothing else that could break? This is a great example of a capability which a distribution may not want to support, due to distribution specific security policies. > > > > > > Option "2" to me looks with a single possible user, and incidentally > > > this single user can already enforce model "2" by only tweaking its > > > seccomp-bpf filters without applying 2/2. It'd be a bug if android > > > apps runs unprotected by seccomp regardless of 2/2. Can you elaborate on what bug is present by processes being unprotected by seccomp? Seccomp cannot be universally applied on Android due to previously mentioned performance concerns. Seccomp is used in Android primarily as a tool to enforce the list of allowed syscalls, so that such syscalls can be audited before being included as part of the Android API. -- Nick -- Nick Kralevich | nnk@google.com