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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28044C61DA7 for ; Fri, 27 Jan 2023 22:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231342AbjA0WgL (ORCPT ); Fri, 27 Jan 2023 17:36:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbjA0WgJ (ORCPT ); Fri, 27 Jan 2023 17:36:09 -0500 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63A647962C for ; Fri, 27 Jan 2023 14:36:04 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id p24so6376850plw.11 for ; Fri, 27 Jan 2023 14:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hg9InPQN4tioHiMOdnKqvlrPm/hTugTIRh5hdEkItHk=; b=IkBYUtYDZafcPWMLulxZiUJSeNAA86Kv8Xpi33/kVI4jpXr82P4LQyDIDQABFSUhas 17MmT36jpLUUQAtas8M7WDGmlJi9YAfYXks0Zx9284ToWbnGxty13qfnO0lfwxAWw5G+ XmsoPUQ++jfe8+g/sdKeTkDE3eiJNE4Yfb0OHE9yJ5Bv6krz6EFTKnbjpLvTzK7ZFLyu H2cIrJ1hsKIq2/P/mfcfHdyWqV1v73KsC2h/vEJvs6GeCNhTmykcht2XBSa19lfgH8ax MZ7PXY2xBsRaxyDJ+e3G/9/39QKW/VOdGZI5Igvu/s3houV1VAvscksWTGUw2lUpA9ci yEfw== 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=hg9InPQN4tioHiMOdnKqvlrPm/hTugTIRh5hdEkItHk=; b=KL9q8ZcoU5v8M6e0aR9J/WcY+GQrod+z1VWy6/RQdbEie4bIN2G4mKYQf9hMmyWmtY liOyOB4tjlYAJoAO9kPFdut+elEwZqMXqw36mOtO+4cldY1hIvq3XyOXkaUcTejhJllf ywys0vazazZ81foYQ09UIv9mrR4CHEDNckZUcQ09FC9EtPBzsyh9SQkCZKlnwyg81zKm dwlWxdOJYsW6HlIsX/FNg7OemIbYhl0rTZXiYzHp2Rf1F2B3uLbeXSbOJDkkAhnPTOA/ 3zBPmimUS9sUBkiZSljgTQaf1x20GAJZ8eO44G51D7WGQJWgAo+6FTzRitqponbm8XE9 lorw== X-Gm-Message-State: AFqh2kqoJrSRtv7y7RhIkKlymWu+jZi0mmeBXgpConUbXAh2AtFIOujj /kk6yvNFkneb9wotUhBZo2OVwCM2STYiBqqNrZlN0eRF12rk X-Google-Smtp-Source: AMrXdXvzWbZmDFbaDAfHsJMk2b5d62SU6fcAEF0ZvE0if6bNDtDttm18NnlrjsNl8TDbMsKuTJp/ByVLd+bOX8i8ai4= X-Received: by 2002:a17:90a:5b0c:b0:223:fa07:7bfb with SMTP id o12-20020a17090a5b0c00b00223fa077bfbmr5371755pji.38.1674858963877; Fri, 27 Jan 2023 14:36:03 -0800 (PST) MIME-Version: 1.0 References: <68eb0c2dd50bca1af91203669f7f1f8312331f38.1674682056.git.rgb@redhat.com> In-Reply-To: <68eb0c2dd50bca1af91203669f7f1f8312331f38.1674682056.git.rgb@redhat.com> From: Paul Moore Date: Fri, 27 Jan 2023 17:35:52 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , io-uring@vger.kernel.org, Eric Paris , Steve Grubb , Stefan Roesch , Christian Brauner , Jens Axboe , Pavel Begunkov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote: > > Since FADVISE can truncate files and MADVISE operates on memory, reverse > the audit_skip tags. > > Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to io_uring") > Signed-off-by: Richard Guy Briggs > --- > io_uring/opdef.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/io_uring/opdef.c b/io_uring/opdef.c > index 3aa0d65c50e3..a2bf53b4a38a 100644 > --- a/io_uring/opdef.c > +++ b/io_uring/opdef.c > @@ -306,12 +306,12 @@ const struct io_op_def io_op_defs[] = { > }, > [IORING_OP_FADVISE] = { > .needs_file = 1, > - .audit_skip = 1, > .name = "FADVISE", > .prep = io_fadvise_prep, > .issue = io_fadvise, > }, I've never used posix_fadvise() or the associated fadvise64*() syscalls, but from quickly reading the manpages and the generic_fadvise() function in the kernel I'm missing where the fadvise family of functions could be used to truncate a file, can you show me where this happens? The closest I can see is the manipulation of the page cache, but that shouldn't actually modify the file ... right? > [IORING_OP_MADVISE] = { > + .audit_skip = 1, > .name = "MADVISE", > .prep = io_madvise_prep, > .issue = io_madvise, I *think* this should be okay, what testing/verification have you done on this? One of the things I like to check is to see if any LSMs might perform an access check and/or generate an audit record on an operation, if there is a case where that could happen we should setup audit properly. I did a very quick check of do_madvise() and nothing jumped out at me, but I would be interested in knowing what testing or verification you did here. -- paul-moore.com 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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D2EC2C54EAA for ; Fri, 27 Jan 2023 22:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674858974; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=KI3HWKmv/I5RU31DSCYUAKQA7+wbAfZ1O8whtJtFlHI=; b=dZds7bvxmj4aejh5BJAxeTo6hyLZWVUcfYupgPK7Oa4hE2eGDOHls5gukUs2cgemOPek36 mhfeATiSCMCTPSkgrT2BPhLMWohPpjKliMK1E031JH8hFABcl/ZRDB2pzkroBenRE5D39n aazWAKsiEprIx82ArgZG8chuzxRjVL8= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-218-LQhmNFVGMd-DoQxUIk20HQ-1; Fri, 27 Jan 2023 17:36:13 -0500 X-MC-Unique: LQhmNFVGMd-DoQxUIk20HQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F1AFC1C05156; Fri, 27 Jan 2023 22:36:11 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id BC6362166B26; Fri, 27 Jan 2023 22:36:09 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 93D54194658D; Fri, 27 Jan 2023 22:36:09 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 6C711194658C for ; Fri, 27 Jan 2023 22:36:08 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id F29F92166B29; Fri, 27 Jan 2023 22:36:07 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast03.extmail.prod.ext.rdu2.redhat.com [10.11.55.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC1AF2166B26 for ; Fri, 27 Jan 2023 22:36:07 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CCD36811E9C for ; Fri, 27 Jan 2023 22:36:07 +0000 (UTC) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-219-ktJrDQhxNAeNnRqi1zQ2Og-1; Fri, 27 Jan 2023 17:36:05 -0500 X-MC-Unique: ktJrDQhxNAeNnRqi1zQ2Og-1 Received: by mail-pl1-f170.google.com with SMTP id g23so6370797plq.12 for ; Fri, 27 Jan 2023 14:36:04 -0800 (PST) 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=hg9InPQN4tioHiMOdnKqvlrPm/hTugTIRh5hdEkItHk=; b=aK5E4tTNv1mO4VOd56UOkNO5RnrkXzVgitIPyttD52jucSXOKPM02ZukdblYjELbyS uXe1cM1Oj9OfWeM7oJcF5mNjyeI/OENoGXUzOh9WD99zxmkVe7u8WV9+eNbMuKE7SfYz eszoYYB4l+822tlOeluULa6rKcCqpOhjcXyWy9FX0NOWkHLH5Z7LNCLNZGjQbwgOLH5O rF0RUck4M7jLAhxcpnARIkKqj/xwUKz6zqjYhCarYp/tUEyWWAfTNS/Ie5uhh7da6M8N GVDcOH6YfbuL6D31eiTjHeyzKlPJuPd9pKHEUlxI0LIE9A0eb8GczeEYGtOFK4+GLhnu VHLw== X-Gm-Message-State: AFqh2koM6T8MW4+YMLBFYdBXZ1U3bHtWBi/Yz1Ao8/pvvkHZNIagJN6q cC3U1HyqRw4rM7WGbCo1PFdG8ZvPxmDk7Z98ks+Q X-Google-Smtp-Source: AMrXdXvzWbZmDFbaDAfHsJMk2b5d62SU6fcAEF0ZvE0if6bNDtDttm18NnlrjsNl8TDbMsKuTJp/ByVLd+bOX8i8ai4= X-Received: by 2002:a17:90a:5b0c:b0:223:fa07:7bfb with SMTP id o12-20020a17090a5b0c00b00223fa077bfbmr5371755pji.38.1674858963877; Fri, 27 Jan 2023 14:36:03 -0800 (PST) MIME-Version: 1.0 References: <68eb0c2dd50bca1af91203669f7f1f8312331f38.1674682056.git.rgb@redhat.com> In-Reply-To: <68eb0c2dd50bca1af91203669f7f1f8312331f38.1674682056.git.rgb@redhat.com> From: Paul Moore Date: Fri, 27 Jan 2023 17:35:52 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] io_uring, audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE To: Richard Guy Briggs X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , Christian Brauner , LKML , Pavel Begunkov , Linux-Audit Mailing List , Stefan Roesch , Eric Paris , io-uring@vger.kernel.org Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Jan 27, 2023 at 12:24 PM Richard Guy Briggs wrote: > > Since FADVISE can truncate files and MADVISE operates on memory, reverse > the audit_skip tags. > > Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to io_uring") > Signed-off-by: Richard Guy Briggs > --- > io_uring/opdef.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/io_uring/opdef.c b/io_uring/opdef.c > index 3aa0d65c50e3..a2bf53b4a38a 100644 > --- a/io_uring/opdef.c > +++ b/io_uring/opdef.c > @@ -306,12 +306,12 @@ const struct io_op_def io_op_defs[] = { > }, > [IORING_OP_FADVISE] = { > .needs_file = 1, > - .audit_skip = 1, > .name = "FADVISE", > .prep = io_fadvise_prep, > .issue = io_fadvise, > }, I've never used posix_fadvise() or the associated fadvise64*() syscalls, but from quickly reading the manpages and the generic_fadvise() function in the kernel I'm missing where the fadvise family of functions could be used to truncate a file, can you show me where this happens? The closest I can see is the manipulation of the page cache, but that shouldn't actually modify the file ... right? > [IORING_OP_MADVISE] = { > + .audit_skip = 1, > .name = "MADVISE", > .prep = io_madvise_prep, > .issue = io_madvise, I *think* this should be okay, what testing/verification have you done on this? One of the things I like to check is to see if any LSMs might perform an access check and/or generate an audit record on an operation, if there is a case where that could happen we should setup audit properly. I did a very quick check of do_madvise() and nothing jumped out at me, but I would be interested in knowing what testing or verification you did here. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit