From patchwork Mon Mar 11 09:36:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 10847123 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 27EF118EC for ; Mon, 11 Mar 2019 09:37:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 16B8C28F79 for ; Mon, 11 Mar 2019 09:37:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0A90728FB5; Mon, 11 Mar 2019 09:37:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B265028FB6 for ; Mon, 11 Mar 2019 09:37:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727125AbfCKJhQ (ORCPT ); Mon, 11 Mar 2019 05:37:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726969AbfCKJhP (ORCPT ); Mon, 11 Mar 2019 05:37:15 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D0F77C057F3C; Mon, 11 Mar 2019 09:37:14 +0000 (UTC) Received: from xz-x1.nay.redhat.com (dhcp-14-116.nay.redhat.com [10.66.14.116]) by smtp.corp.redhat.com (Postfix) with ESMTP id C95C05D705; Mon, 11 Mar 2019 09:37:02 +0000 (UTC) From: Peter Xu To: linux-kernel@vger.kernel.org Cc: Paolo Bonzini , Hugh Dickins , Luis Chamberlain , Maxime Coquelin , kvm@vger.kernel.org, Jerome Glisse , Pavel Emelyanov , Johannes Weiner , peterx@redhat.com, Martin Cracauer , Denis Plotnikov , linux-mm@kvack.org, Marty McFadden , Maya Gokhale , Mike Kravetz , Andrea Arcangeli , Mike Rapoport , Kees Cook , Mel Gorman , "Kirill A . Shutemov" , linux-fsdevel@vger.kernel.org, "Dr . David Alan Gilbert" , Andrew Morton Subject: [PATCH 0/3] userfaultfd: allow to forbid unprivileged users Date: Mon, 11 Mar 2019 17:36:58 +0800 Message-Id: <20190311093701.15734-1-peterx@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 11 Mar 2019 09:37:15 +0000 (UTC) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, (The idea comes from Andrea, and following discussions with Mike and other people) This patchset introduces a new sysctl flag to allow the admin to forbid users from using userfaultfd: $ cat /proc/sys/vm/unprivileged_userfaultfd [disabled] enabled kvm - When set to "disabled", all unprivileged users are forbidden to use userfaultfd syscalls. - When set to "enabled", all users are allowed to use userfaultfd syscalls. - When set to "kvm", all unprivileged users are forbidden to use the userfaultfd syscalls, except the user who has permission to open /dev/kvm. This new flag can add one more layer of security to reduce the attack surface of the kernel by abusing userfaultfd. Here we grant the thread userfaultfd permission by checking against CAP_SYS_PTRACE capability. By default, the value is "disabled" which is the most strict policy. Distributions can have their own perferred value. The "kvm" entry is a bit special here only to make sure that existing users like QEMU/KVM won't break by this newly introduced flag. What we need to do is simply set the "unprivileged_userfaultfd" flag to "kvm" here to automatically grant userfaultfd permission for processes like QEMU/KVM without extra code to tweak these flags in the admin code. Patch 1: The interface patch to introduce the flag Patch 2: The KVM related changes to detect opening of /dev/kvm Patch 3: Apply the flag to userfaultfd syscalls All comments would be greatly welcomed. Thanks, Peter Xu (3): userfaultfd/sysctl: introduce unprivileged_userfaultfd kvm/mm: introduce MMF_USERFAULTFD_ALLOW flag userfaultfd: apply unprivileged_userfaultfd check fs/userfaultfd.c | 121 +++++++++++++++++++++++++++++++++ include/linux/sched/coredump.h | 1 + include/linux/userfaultfd_k.h | 5 ++ init/Kconfig | 11 +++ kernel/sysctl.c | 11 +++ virt/kvm/kvm_main.c | 7 ++ 6 files changed, 156 insertions(+) Reviewed-by: Mike Rapoport