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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C4D8C47080 for ; Sat, 22 May 2021 02:36:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD3EC6138C for ; Sat, 22 May 2021 02:36:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231160AbhEVCiT (ORCPT ); Fri, 21 May 2021 22:38:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230493AbhEVCiS (ORCPT ); Fri, 21 May 2021 22:38:18 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83764C0613ED for ; Fri, 21 May 2021 19:36:53 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id j10so7837601edw.8 for ; Fri, 21 May 2021 19:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/bYvAACSgc8/uW7uI1cczUf6zncLtiw3niodFFHXbfQ=; b=zueRaqvi0ABnvezPF7a/BvC89XCqv9MA5lpZVc06qJfZkfTl6XHxnBOB/b37aSowba MvmSbZcggtkx+qjxr+EQ8Vt4UbkoAt9GxSaZcQWxj+cXScSaCGqbmirFZ3ycLfQgLS/9 WMEhgZTGZ+Jyxu49B0c2KfgCbz4b0bJfFQtZl+2Vauh5sD/CpwxFmg9xTbxyFIE5c6Qq a5Oo9V20+jqFrSCcPiFpYwKUeTyINRxOIsc57wXIsZFUmGXsNtcROoIzG3rhmdETAJj3 XfuB/9Adbbapv5EF6kx5uRfFhVUGUWtZ6qINh5fUAFO5uZJXq2fxmJfHd2s/zAercPZD AZpg== 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=/bYvAACSgc8/uW7uI1cczUf6zncLtiw3niodFFHXbfQ=; b=I1aZvuwUfZwVzWQ1g2nCiHx/ABOBLyTdGt5hcmNQqI4n98cn69ALosR2I70iew5gj9 M7SKg2s/5b4aUzUshegkQXs8H0XJWAs74GhtxigvuSrwGEB3sc/OMgas8IdjTlOtVHUO PCgKwEognI+Ez9a/idx0lVkc0g9+pADge2mtP3cJd1O3ef9+ezCb70MNlSgJJ3ydLTBp FekPr2oEJjIVOPa6GFf3XABQbrncsetn34MHBGmYH/uFiss3r8Q43JBhO27Bhio6nV61 HbuYOSmKOvyP9k/B5gzG4M2hJdKuaFpxrLhkqiehJ0jBRKmo9MryLRu2PnDyVlAteETx +2JQ== X-Gm-Message-State: AOAM532cn+frNcx4To3pJ1tJjSAXH2r3m9MhQ0RpITw1Q0VtCwst+1HT Go6W0lQ6DBo5/zO9XqEMio0MZAd+TvPdGr6y0za4 X-Google-Smtp-Source: ABdhPJz9UvC/faFDkiRLsiBXVJ9IkfixZn9C7UN/IQ22MxEe2N1Eq1BZgP//f1I2SXPZB1KVfu8b/AJWi+UrvHYAZ34= X-Received: by 2002:aa7:c349:: with SMTP id j9mr13964677edr.135.1621651012073; Fri, 21 May 2021 19:36:52 -0700 (PDT) MIME-Version: 1.0 References: <162163367115.8379.8459012634106035341.stgit@sifl> <162163379461.8379.9691291608621179559.stgit@sifl> In-Reply-To: From: Paul Moore Date: Fri, 21 May 2021 22:36:40 -0400 Message-ID: Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring To: Pavel Begunkov Cc: linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-audit@redhat.com, io-uring@vger.kernel.org, linux-fsdevel@vger.kernel.org, Kumar Kartikeya Dwivedi , Jens Axboe , Alexander Viro Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, May 21, 2021 at 8:22 PM Pavel Begunkov wrote: > On 5/21/21 10:49 PM, Paul Moore wrote: > > WARNING - This is a work in progress and should not be merged > > anywhere important. It is almost surely not complete, and while it > > probably compiles it likely hasn't been booted and will do terrible > > things. You have been warned. > > > > This patch adds basic auditing to io_uring operations, regardless of > > their context. This is accomplished by allocating audit_context > > structures for the io-wq worker and io_uring SQPOLL kernel threads > > as well as explicitly auditing the io_uring operations in > > io_issue_sqe(). The io_uring operations are audited using a new > > AUDIT_URINGOP record, an example is shown below: > > > > % > > > > Thanks to Richard Guy Briggs for review and feedback. > > > > Signed-off-by: Paul Moore > > --- > [...] > > diff --git a/fs/io_uring.c b/fs/io_uring.c > > index e481ac8a757a..e9941d1ad8fd 100644 > > --- a/fs/io_uring.c > > +++ b/fs/io_uring.c > > @@ -78,6 +78,7 @@ > > #include > > #include > > #include > > +#include > > > > #define CREATE_TRACE_POINTS > > #include > > @@ -6105,6 +6106,9 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags) > > if (req->work.creds && req->work.creds != current_cred()) > > creds = override_creds(req->work.creds); > > > > + if (req->opcode < IORING_OP_LAST) > > always true at this point I placed the opcode check before the audit call because the switch statement below which handles the operation dispatching has a 'ret = -EINVAL' for the default case, implying that there are some paths where an invalid opcode could be passed into the function. Obviously if that is not the case and you can guarantee that req->opcode will always be valid we can easily drop the check prior to the audit call. > > + audit_uring_entry(req->opcode); > > So, it adds two if's with memory loads (i.e. current->audit_context) > per request in one of the hottest functions here... No way, nack > > Maybe, if it's dynamically compiled into like kprobes if it's > _really_ used. I'm open to suggestions on how to tweak the io_uring/audit integration, if you don't like what I've proposed in this patchset, lets try to come up with a solution that is more palatable. If you were going to add audit support for these io_uring operations, how would you propose we do it? Not being able to properly audit io_uring operations is going to be a significant issue for a chunk of users, if it isn't already, we need to work to find a solution to this problem. Unfortunately I don't think dynamically inserting audit calls is something that would meet the needs of the audit community (I fear it would run afoul of the various security certifications), and it definitely isn't something that we support at present. -- paul moore www.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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D83ACC04FF3 for ; Sat, 22 May 2021 02:37:10 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 505046135B for ; Sat, 22 May 2021 02:37:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 505046135B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-5-_OwyB924PWeQAhUFt-ZHDA-1; Fri, 21 May 2021 22:37:04 -0400 X-MC-Unique: _OwyB924PWeQAhUFt-ZHDA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BCD1E107ACC7; Sat, 22 May 2021 02:37:00 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 86CFC177F1; Sat, 22 May 2021 02:37:00 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id D338A1800BB4; Sat, 22 May 2021 02:36:59 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 14M2av5R014270 for ; Fri, 21 May 2021 22:36:57 -0400 Received: by smtp.corp.redhat.com (Postfix) id 8F2D011FC85; Sat, 22 May 2021 02:36:57 +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 897851649C3 for ; Sat, 22 May 2021 02:36:55 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (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 3973880D0E0 for ; Sat, 22 May 2021 02:36:55 +0000 (UTC) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-400-T-KqV8HANkul_7k3VS7DIg-1; Fri, 21 May 2021 22:36:53 -0400 X-MC-Unique: T-KqV8HANkul_7k3VS7DIg-1 Received: by mail-ed1-f41.google.com with SMTP id o5so16386541edc.5 for ; Fri, 21 May 2021 19:36:53 -0700 (PDT) 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=/bYvAACSgc8/uW7uI1cczUf6zncLtiw3niodFFHXbfQ=; b=Akcd9a/5MzeVOUMUI4klRgQMYfA/kgvVwAL9xvTtj2K3V9eB10eYJ5LluGMA1VsXTh ebXaaoepeea2gRtKWbmYrLgMh5WkKhD986VMt//owOxgoV9vDuREvqUMjKLVY9kBdY8q 4XBWEBBTKCseior9jbuETJdjDocQ/WPlba8DxOKdyVPIBOZT0EybSzNt+Cz/gL/qoJPm Ep+zSvStIjfeScCyzEG8PNMNE8aXnKkg4hKQnW/mwkxLkIH0xCIBc7xIJXoamLD9DFW7 31IySo9NX2IatOma9fXJwd4SI20pGjM94QNDpiG3zQR6x3TFYACc+ax0d4vKl19a8wOM bfHA== X-Gm-Message-State: AOAM533a/aiCvS1HEb/L8fR1QBKVp4rXsrmBtAkCi1t5PicNEqwm88hD QfdjuDGYXUYXaOtXBZolhrvn3rpw2Cu1NE+190mM X-Google-Smtp-Source: ABdhPJz9UvC/faFDkiRLsiBXVJ9IkfixZn9C7UN/IQ22MxEe2N1Eq1BZgP//f1I2SXPZB1KVfu8b/AJWi+UrvHYAZ34= X-Received: by 2002:aa7:c349:: with SMTP id j9mr13964677edr.135.1621651012073; Fri, 21 May 2021 19:36:52 -0700 (PDT) MIME-Version: 1.0 References: <162163367115.8379.8459012634106035341.stgit@sifl> <162163379461.8379.9691291608621179559.stgit@sifl> In-Reply-To: From: Paul Moore Date: Fri, 21 May 2021 22:36:40 -0400 Message-ID: Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring To: Pavel Begunkov 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 2.79 on 10.11.54.5 X-loop: linux-audit@redhat.com Cc: Jens Axboe , selinux@vger.kernel.org, linux-security-module@vger.kernel.org, linux-audit@redhat.com, Kumar Kartikeya Dwivedi , linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, Alexander Viro X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, May 21, 2021 at 8:22 PM Pavel Begunkov wrote: > On 5/21/21 10:49 PM, Paul Moore wrote: > > WARNING - This is a work in progress and should not be merged > > anywhere important. It is almost surely not complete, and while it > > probably compiles it likely hasn't been booted and will do terrible > > things. You have been warned. > > > > This patch adds basic auditing to io_uring operations, regardless of > > their context. This is accomplished by allocating audit_context > > structures for the io-wq worker and io_uring SQPOLL kernel threads > > as well as explicitly auditing the io_uring operations in > > io_issue_sqe(). The io_uring operations are audited using a new > > AUDIT_URINGOP record, an example is shown below: > > > > % > > > > Thanks to Richard Guy Briggs for review and feedback. > > > > Signed-off-by: Paul Moore > > --- > [...] > > diff --git a/fs/io_uring.c b/fs/io_uring.c > > index e481ac8a757a..e9941d1ad8fd 100644 > > --- a/fs/io_uring.c > > +++ b/fs/io_uring.c > > @@ -78,6 +78,7 @@ > > #include > > #include > > #include > > +#include > > > > #define CREATE_TRACE_POINTS > > #include > > @@ -6105,6 +6106,9 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags) > > if (req->work.creds && req->work.creds != current_cred()) > > creds = override_creds(req->work.creds); > > > > + if (req->opcode < IORING_OP_LAST) > > always true at this point I placed the opcode check before the audit call because the switch statement below which handles the operation dispatching has a 'ret = -EINVAL' for the default case, implying that there are some paths where an invalid opcode could be passed into the function. Obviously if that is not the case and you can guarantee that req->opcode will always be valid we can easily drop the check prior to the audit call. > > + audit_uring_entry(req->opcode); > > So, it adds two if's with memory loads (i.e. current->audit_context) > per request in one of the hottest functions here... No way, nack > > Maybe, if it's dynamically compiled into like kprobes if it's > _really_ used. I'm open to suggestions on how to tweak the io_uring/audit integration, if you don't like what I've proposed in this patchset, lets try to come up with a solution that is more palatable. If you were going to add audit support for these io_uring operations, how would you propose we do it? Not being able to properly audit io_uring operations is going to be a significant issue for a chunk of users, if it isn't already, we need to work to find a solution to this problem. Unfortunately I don't think dynamically inserting audit calls is something that would meet the needs of the audit community (I fear it would run afoul of the various security certifications), and it definitely isn't something that we support at present. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit