Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7221006ybf; Fri, 6 Mar 2020 12:50:00 -0800 (PST) X-Google-Smtp-Source: ADFU+vvbq09E5WN3N4+mGHHBKXB2XeaF9Q3XDdCESvKPTJI6hO8ZpQMJPy09BGBtS1gPxmcuFgDj X-Received: by 2002:a9d:ed1:: with SMTP id 75mr4322594otj.229.1583527800401; Fri, 06 Mar 2020 12:50:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583527800; cv=none; d=google.com; s=arc-20160816; b=zR3plKOH+PjOkR15zGqqgYfmYMFu4/bo6h9HXX7htcaOE8qkIMkLU5xHoQCRYMGsAY iBUmkv76CJLa/+7GXcnWu10NtxBdeshYpVBID89HN/1wY8Pkk4piGaJfhMVrThtOdtn5 cb/ndh/8l3QL6NAe2uNbY1QQfFKPXudJIFpqEJfMuGCIhN6vanLmyuUljimUQh6yvBhw FDeq0y2mWqiPqaq1Ixe1+9d+CR1v/R1KyW6Vr87OrZ3PZI35qVaZoPC8cdMUk0SLQahM NhcmfgVCyNeqHAyCjWieYD85m0sMZelgmJNTBYhJXI2+9czm99uWOFDV+lnumIpA5nvk xfsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Vnq654icNMC3OPciKhsbNTJjnPlwkjnJ6PM6ZwzuRt4=; b=jH1FgWEwkuB5o/jHwllJbd79YIhiQljdHiYshAvYTflXwhTF3P+EC6ewRY0aT8zFts dfa9NgN8oJKqHbvLJgJ6jJWgTg8sECyUCx0my/hwHgLWNs39GiYz5dHEi+cctWsAw0+i rDIVq6LlGiJX+OGabFlalspL3eQmJowd9CdAvNVukocJbnh99ZbytsW9taNP+/aO37lV uXg2R8AoGhL/sxuGWtRoh6kPnK/u6oVuo1D+nraINlPB2xOvJoMKnkx+WP9oZj57QQWa Z/RqrNBC3e8s8aGXt+qZzeI1gC6Pm3yqxandUIF/4OlzEEEeFGPe27aaqwuEYMRd+3rR gZfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BoDSQ8+z; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z2si280463oix.100.2020.03.06.12.49.39; Fri, 06 Mar 2020 12:50:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BoDSQ8+z; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726498AbgCFUtP (ORCPT + 99 others); Fri, 6 Mar 2020 15:49:15 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:44064 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726090AbgCFUtN (ORCPT ); Fri, 6 Mar 2020 15:49:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583527752; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vnq654icNMC3OPciKhsbNTJjnPlwkjnJ6PM6ZwzuRt4=; b=BoDSQ8+zWviWWWVEp6YvBv+utspByJKFns2RI0bRjEWNQE4sNZd+uzlyinEU6lKIwXjYD/ qeeZt/7tbQSdnKUlxZNbwldXPmYGjUjh82oUv7Z5KBC3i3a/zHngMd5AUXu9ymNe7DbhQd dUhg7LGppHIY/HU75RZ1WoxZ8zRrs3U= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-98-2Z-QhHiFMDiUKyg5WMbJ5g-1; Fri, 06 Mar 2020 15:49:08 -0500 X-MC-Unique: 2Z-QhHiFMDiUKyg5WMbJ5g-1 Received: by mail-il1-f200.google.com with SMTP id d2so2450607ilf.19 for ; Fri, 06 Mar 2020 12:49:08 -0800 (PST) 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=Vnq654icNMC3OPciKhsbNTJjnPlwkjnJ6PM6ZwzuRt4=; b=ABqatW60FFeDhBVJw1JPDelpxnkhgzW+xIm4Xt4XSSTRQf7WzbdeLCWDxTaNj0uXNl qxcyfcvH2OhfrDNhc2HP69W6N0TktQSmUMaspmj07yqtBllM1m9MwxcdDPKOyPArLQlt VBEWy/UFdc6AegAtnuuGZB5ELcFsR31dW9PlTL9sMhFCvREoJpRtEsbDgyb6+wTdj2rf Z+Cp9q1xlUbBwdi0fVtVOhC1jeAOPukN1KSW8EPfeKVs39vtWyBLCIV1UWotXp06+m7R ITOjbeWTBsVnDnalOMSyc5EyM1oTI6tC9EmZibIyMah8aVzeBsGmpFKPy23w5t85WgbZ NggQ== X-Gm-Message-State: ANhLgQ1Fad9Hk09hSvBBQkOaJ4Dt8pJ5P2IMHBUwYUiWMu/RwuF+WZ8K YO0sXAiHk/Sj26feE+J+9NfWfYfGfSDIgVsl9XSu9x4Wf9FSyO3fweuYs+eeE+JoC7IvUhmSiDe LzIDRLTy36H6GGQ1iSr0QMtthIszQdN+0Ff/8eQ7g X-Received: by 2002:a92:bb93:: with SMTP id x19mr4950275ilk.304.1583527748221; Fri, 06 Mar 2020 12:49:08 -0800 (PST) X-Received: by 2002:a92:bb93:: with SMTP id x19mr4950241ilk.304.1583527747749; Fri, 06 Mar 2020 12:49:07 -0800 (PST) MIME-Version: 1.0 References: <20200306172010.1213899-1-ckuehl@redhat.com> In-Reply-To: <20200306172010.1213899-1-ckuehl@redhat.com> From: Nathaniel McCallum Date: Fri, 6 Mar 2020 15:48:57 -0500 Message-ID: Subject: Re: [PATCH 0/1] crypto: ccp: use file mode for sev ioctl permissions To: Connor Kuehl Cc: "Lendacky, Thomas" , Herbert Xu , davem@davemloft.net, "Hook, Gary" , erdemaktas@google.com, rientjes@google.com, "Singh, Brijesh" , Bandan Das , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Mar 6, 2020 at 12:20 PM Connor Kuehl wrote: > > Some background: > > My team is working on a project that interacts very closely with > SEV so we have a layer of code that wraps around the SEV ioctl calls. > We have an automated test suite that ends up testing these ioctls > on our test machine. > > We are in the process of adding this test machine as a dedicated test > runner in our continuous integration process. Any time someone opens a > pull request against our project, this test runner automatically checks > that code out and executes the tests. > > Right now, the SEV ioctls that affect the state of the platform require > CAP_SYS_ADMIN to run. This is not a capability we can give to an > automated test runner, because it means that anyone who would like to > contribute to the project would be able to run any code they want (for > good or evil) as CAP_SYS_ADMIN on our machine. > > This patch replaces the check for CAP_SYS_ADMIN with a check that can > still be easily controlled by an administrator with the file permissions > ACL. This way access to the device can still be controlled, but without > also assigning such broad system privileges at the same time. > > Connor Kuehl (1): > crypto: ccp: use file mode for sev ioctl permissions > > drivers/crypto/ccp/sev-dev.c | 33 +++++++++++++++++---------------- > 1 file changed, 17 insertions(+), 16 deletions(-) > > -- > 2.24.1 > One additional note is that this permission structure is more flexible for general SEV usage anyway, and isn't special-case for our usage. Currently, the SEV admin commands are mostly limited to public key certificate management. I would imagine that it would be desirable to have a sev-admin account which can automate the certificate management without having CAP_SYS_ADMIN for the rest of the system. So we believe this patch has broader applicability than just our corner case.