Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2484668rwb; Mon, 7 Nov 2022 13:59:44 -0800 (PST) X-Google-Smtp-Source: AMsMyM6uI6phu1DwGoLaH+biEANGCr07Gy+blawqFLWYrqz1DcMWq6nbmSxWZdcRhqNTVaLar7SN X-Received: by 2002:a63:5063:0:b0:46e:cd36:ce0c with SMTP id q35-20020a635063000000b0046ecd36ce0cmr45994975pgl.617.1667858384338; Mon, 07 Nov 2022 13:59:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667858384; cv=none; d=google.com; s=arc-20160816; b=ELF12aDnnTGDQuXIc2De5DR6DdO3WK6aDh9FjdmRoWSYgXKR0r8Z+8mieIbapsN0PC hqtzFs86Zms6NDwkfVDFvGDFNUjzS0SjU/otFPiD8YA+OmzoqJ0BbhdyT2KPnakwTQAR Wm075+iy4Q/wtx3eZaukzCz4ZaSSDmpQejl8dDk+ZrOgC6aBgz9eYjio/zjzy1uWAXwK 7UyVdLhdHY4VGE/89wCc2adsR/7rnwh1c3KdulOXUJkNcnbSZbzEbseVRrOxTKf3cqcQ Yxe5kZ63XDcghghgoqeyI1HEC9oVXg5DxHSZwe4Mh7Hcpt5ls3f1WbmK8ejHcGfgDUco Wc2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=pHms/O+9VBq8irGp3MyiuJlyANLL/CCV2NFYd5lytyA=; b=f+YL5/lWVLwqJTd6h8+zVbiE2pSACoNAYC3BnGq2WD5d34iRlejcPSH3uHIdrgXSwk 2pKrzATFlzZR9YWZ+V1kdwGzHtE9wy42SAs6rIyZfwgtsonbaESAszeAs1TYTokWdNpc RiIJS5MI2QvAyvZQBxC6eVi3EZpors+hm+7mItjHUBYry2NOWt+PNG+GT55hdJaEqSBv msOAGGe15DcRq9PAg5F8dVftRrgGgUFDISe6iJTUenjLfR2nK/smKRcJDlP0buclfcIv wSHXJTYJp4hMj17+8DBa1NhrnHtvodpq6PqPHHCfos6N1R74r/Y8ONeVsvoayMJEvEdq 5YeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=fbz0dJ0X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f12-20020a170902860c00b001873a81f2d1si10095243plo.87.2022.11.07.13.59.32; Mon, 07 Nov 2022 13:59:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=fbz0dJ0X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232984AbiKGVRt (ORCPT + 91 others); Mon, 7 Nov 2022 16:17:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233426AbiKGVRc (ORCPT ); Mon, 7 Nov 2022 16:17:32 -0500 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29AB313CDD for ; Mon, 7 Nov 2022 13:13:37 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id h132so5676291oif.2 for ; Mon, 07 Nov 2022 13:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pHms/O+9VBq8irGp3MyiuJlyANLL/CCV2NFYd5lytyA=; b=fbz0dJ0XnDpsx+hMge6yfECCLrQ9kRAHBi+2sKrgralxQwXVYVPHT1wlH0vOI9aXS8 Q69Cl3BJx4YPMF4NRILvqzetKOldQMWspeGTkz0lcPKpFBHfezWWbmdr/ZwTypsvUFdJ g5J3srFyn2ZUZP5+9zDAEtyqAlGXF0vIdYcpbhgL85wp04jFhnedzI1rRnmZjWbn6RAL mYWri7hGGN55fKqX+3zh9NzgGpFjgaC7vxXACDyVgFcJ4ZkzpfW7oo1SQYpXUBAmPu8Y 6jkwwIrJAv0O2KHOkdhSm95DZ/t0cfAUEvg9DHWvzYQvYg8crJo1G2MC38vRRwBc4bkh 4FhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pHms/O+9VBq8irGp3MyiuJlyANLL/CCV2NFYd5lytyA=; b=tdfzW6ftszKXA4fifC4sYFHcNieu01dCWriXoeyjHn7nhjAuJgngHUfIZYeVVCx37P re4EJXOJpQsM4URp0l86c+DLdVdenFsm2lHScmG/PB90rx1vF3L1wn78zJ747PnUkABi Ibs7n0yoryZA3moL4vrJ2IFisiRj+43vfWSYGJv+IJNMKLFm4/kYg1xwBYFMri1eCGA1 Xc+fZqGzFE5aClx2urt3/uwD3ALnJsr2jEXDW/h70z4paMLgNo7hTBM1DuRnUH9GBL+/ c/TK7j/P1znvT9pvuDLBCxXcaNXfCXrBzj69ZYETl8upYMuuchsOsEVcivOqK4xZ5vGx Sw1w== X-Gm-Message-State: ACrzQf0i3R4s7Qq+ozIZp0MAGCh1vjbphBLsW443wZLwgaWrXGmcKqrP RsUcULvrfyTLQMJ1bDuBX1HrTMQt8b34IpYJThqW X-Received: by 2002:a05:6808:1441:b0:35a:4a2d:673b with SMTP id x1-20020a056808144100b0035a4a2d673bmr14688971oiv.172.1667855616463; Mon, 07 Nov 2022 13:13:36 -0800 (PST) MIME-Version: 1.0 References: <20221107205754.2635439-1-cukie@google.com> In-Reply-To: <20221107205754.2635439-1-cukie@google.com> From: Paul Moore Date: Mon, 7 Nov 2022 16:13:25 -0500 Message-ID: Subject: Re: [PATCH v1 0/2] Add LSM access controls for io_uring_setup To: Gil Cukierman Cc: Jens Axboe , Pavel Begunkov , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , kernel-team@android.com, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 7, 2022 at 3:58 PM Gil Cukierman wrote: > > This patchset provides the changes required for controlling access to > the io_uring_setup system call by LSMs. It does this by adding a new > hook to io_uring. It also provides the SELinux implementation for a new > permission, io_uring { setup }, using the new hook. > > This is important because existing io_uring hooks only support limiting > the sharing of credentials and access to the sensitive uring_cmd file > op. Users of LSMs may also want the ability to tightly control which > callers can retrieve an io_uring capable fd from the kernel, which is > needed for all subsequent io_uring operations. It isn't immediately obvious to me why simply obtaining a io_uring fd from io_uring_setup() would present a problem, as the security relevant operations that are possible with that io_uring fd *should* still be controlled by other LSM hooks. Can you help me understand what security issue you are trying to resolve with this control? -- paul-moore.com