Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88C6CC636BD for ; Sat, 28 Jan 2023 00:07:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232665AbjA1AHn (ORCPT ); Fri, 27 Jan 2023 19:07:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232288AbjA1AHj (ORCPT ); Fri, 27 Jan 2023 19:07:39 -0500 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 763DB8663B for ; Fri, 27 Jan 2023 16:07:29 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id e10so4221468pgc.9 for ; Fri, 27 Jan 2023 16:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2A/Zg0V6mGpRrWbIuZ1WrswW+49OQc7hs6M62c327v4=; b=bKX0PfG9IW1cUXUKM7Mxe7p2uhDtsdSaiECHRswG7K80hHqwsUZHSCcOONA7KTGoKn WoLwxBWXZQPke5jVRofxheCvsoJpsyd7/hbQ3EbHG5KQo6PZ+3q+Nb0+blE4gPy/yaRj jkBHtcyxxOOnSeI+H+tEw77v8oLsIxqT0kAlZyVT+2HVAYGgSaYR12HRgJSfY6blCmHZ cJbV4KPl31+QqiXVZgKIQe3fGnwxEI8E2IJU2CdAu6ucriD5Ab5lcfe7xUVEeAdmLa/Z 5jA6iNfsqB5XHL5cxxAMvd53HjQbttZ5rDlp6NoOeh9TT8hLxq0XLi5xe3RxyebD6xTg CrEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=2A/Zg0V6mGpRrWbIuZ1WrswW+49OQc7hs6M62c327v4=; b=V7nGluFne5B6+gfgWr0dbUXQ4NTpXNLQtjwcG3rci3pnxbFzQMl9BrGyZCZvuxLSWi OZspoZxeeuhA6vz5wwiG0MuQanMwpLoiNdqTtppkd3wvBqmp43zwy6Ya5c3HCA5oOzMx WsdvJ3vVelOSNumNpN6Q/Y0/nHDIqaGjW551hI88AEmKRNdswHmfLgxnP42JdPA3hWZY WQV3gCeFnfNV8VKcPrZzfw1ukarQsWeNJSCqQQ5bK0Cm+WzAuCsjnTUrfUz9tJgN87ZH xSDq71K06/pnitrGHKkPRV54tfRTGhexUCI/xjHUuoV78k7YkcJSGnxoyeH2Uin//cM7 FWmA== X-Gm-Message-State: AFqh2krSf9ZP4/klRv8fQAoshlfBVqbtOikGIqJAWCRSymoa9OvZL7WQ b9YSMip2LxyORW/LbNINhEnhymaQzZnnTPi05CuaHm/HP8+w X-Google-Smtp-Source: AMrXdXu4JO49N65C/MOynyZpgVpmlsh4riJCNBfaQ5OEUTtGhSYC7W10mjEhYOOv27I64fmXzLHkjjfsYpdMGPAGwO4= X-Received: by 2002:a65:58c1:0:b0:4d0:1233:d369 with SMTP id e1-20020a6558c1000000b004d01233d369mr4575134pgu.88.1674864448918; Fri, 27 Jan 2023 16:07:28 -0800 (PST) MIME-Version: 1.0 References: <5270af37-5544-42de-4e3f-c437889944dd@kernel.dk> In-Reply-To: <5270af37-5544-42de-4e3f-c437889944dd@kernel.dk> From: Paul Moore Date: Fri, 27 Jan 2023 19:07:17 -0500 Message-ID: Subject: Re: [PATCH v1 2/2] io_uring,audit: do not log IORING_OP_*GETXATTR To: Jens Axboe Cc: Richard Guy Briggs , LKML , io-uring@vger.kernel.org, Eric Paris , Steve Grubb , Stefan Roesch , Christian Brauner , Pavel Begunkov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 27, 2023 at 6:05 PM Jens Axboe wrote: > On 1/27/23 4:01=E2=80=AFPM, Richard Guy Briggs wrote: > > On 2023-01-27 17:43, Paul Moore wrote: > >> On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs w= rote: > >>> Getting XATTRs is not particularly interesting security-wise. > >>> > >>> Suggested-by: Steve Grubb > >>> Fixes: a56834e0fafe ("io_uring: add fgetxattr and getxattr support") > >>> Signed-off-by: Richard Guy Briggs > >>> --- > >>> io_uring/opdef.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >> > >> Depending on your security policy, fetching file data, including > >> xattrs, can be interesting from a security perspective. As an > >> example, look at the SELinux file/getattr permission. > >> > >> https://github.com/SELinuxProject/selinux-notebook/blob/main/src/objec= t_classes_permissions.md#common-file-permissions > > > > The intent here is to lessen the impact of audit operations. Read and > > Write were explicitly removed from io_uring auditing due to performance > > concerns coupled with the denial of service implications from sheer > > volume of records making other messages harder to locate. Those > > operations are still possible for syscall auditing but they are strongl= y > > discouraged for normal use. > > > > If the frequency of getxattr io_uring ops is so infrequent as to be no > > distraction, then this patch may be more of a liability than a benefit. > > (audit list removed) > > Right now the xattr related functions are io-wq driven, and hence not > super performance sensitive. But I'd greatly prefer to clean these up > regardless, because once opcodes get upgraded from needing io-wq, then > we don't have to go through the audit discussion at that point. Better > to do it upfront, like now, regardless of expectation of frequency of > calls. See my reply to Richard, but unfortunately we need to continue to audit the getxattr ops. --=20 paul-moore.com