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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 4EF21C47083 for ; Wed, 2 Jun 2021 19:46:38 +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 B0ADF60C40 for ; Wed, 2 Jun 2021 19:46:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0ADF60C40 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-171-0VpOBss0Mdand75b40pyaw-1; Wed, 02 Jun 2021 15:46:34 -0400 X-MC-Unique: 0VpOBss0Mdand75b40pyaw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 60FB3107ACF8; Wed, 2 Jun 2021 19:46:31 +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 3203A18A61; Wed, 2 Jun 2021 19:46:30 +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 8095F1801264; Wed, 2 Jun 2021 19:46:28 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 152JkPYr019440 for ; Wed, 2 Jun 2021 15:46:26 -0400 Received: by smtp.corp.redhat.com (Postfix) id B1DA111558AE; Wed, 2 Jun 2021 19:46:25 +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 ADA4811558AD for ; Wed, 2 Jun 2021 19:46:23 +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 5647180D0E8 for ; Wed, 2 Jun 2021 19:46:23 +0000 (UTC) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-286-SGp9_iQoPKeY23pwxPjRJA-1; Wed, 02 Jun 2021 15:46:21 -0400 X-MC-Unique: SGp9_iQoPKeY23pwxPjRJA-1 Received: by mail-ed1-f51.google.com with SMTP id r11so4291080edt.13 for ; Wed, 02 Jun 2021 12:46:20 -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=LqoEKJiVAWZlSSI9JgAO1d0PhyXvjYnfYNG32/S+e5M=; b=cfSwYVpepGhrOlo/EmIAkJZC2WHiou5/nmsntSsCbQrIOe1kiiVqBBZ8iyRIkjWjH0 8VrS5NG+hzjnaHLMxTEzhP2CkenC1lCz5cjvVZyAF6HQGhOzQjhWW3mc7UzarDixQVE/ eSIJ+iRwxbYjGtIIaiWjH4NoHrw/eQtB03V1pbI0kVyPZFiBcT91hJaWYRKlOAZKv/7e D4k/OZ7BHErbLPCsS00p33ZAmkhzPaCQFwcAEKbnmM6z+kG9mfUEFGXb1ZB7dSrz/sRz gGFRwbtetcv4FYix1fEedBt0kKTJDy0EnQQAOWQ58/UUrE/jWHuslZoqQGjUat+mfNy/ MgiA== X-Gm-Message-State: AOAM532D49cQlxB2uS45u3ktUz21M/MPBc0fVsxMycWGhpQB861BJ5fs eueIb8pxr7wsjQCRDIEa9pBtL79iKJ0MDqMXkQMU X-Google-Smtp-Source: ABdhPJyuLy2X/c63hvfm+x3eKVgUZz+1DStQP3zkb//f5hhY17s9fx1FxgbH/tqGdqyXbTZs3U+uNHV5N9KUTgXL4f8= X-Received: by 2002:a05:6402:35d4:: with SMTP id z20mr40197715edc.164.1622663179644; Wed, 02 Jun 2021 12:46:19 -0700 (PDT) MIME-Version: 1.0 References: <162163367115.8379.8459012634106035341.stgit@sifl> <162163379461.8379.9691291608621179559.stgit@sifl> <162219f9-7844-0c78-388f-9b5c06557d06@gmail.com> <8943629d-3c69-3529-ca79-d7f8e2c60c16@kernel.dk> <9e69e4b6-2b87-a688-d604-c7f70be894f5@kernel.dk> <3bef7c8a-ee70-d91d-74db-367ad0137d00@kernel.dk> <94e50554-f71a-50ab-c468-418863d2b46f@gmail.com> In-Reply-To: <94e50554-f71a-50ab-c468-418863d2b46f@gmail.com> From: Paul Moore Date: Wed, 2 Jun 2021 15:46:08 -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.78 on 10.11.54.3 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.14 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 Wed, Jun 2, 2021 at 4:27 AM Pavel Begunkov wrote: > On 5/28/21 5:02 PM, Paul Moore wrote: > > On Wed, May 26, 2021 at 4:19 PM Paul Moore wrote: > >> ... If we moved the _entry > >> and _exit calls into the individual operation case blocks (quick > >> openat example below) so that only certain operations were able to be > >> audited would that be acceptable assuming the high frequency ops were > >> untouched? My initial gut feeling was that this would involve >50% of > >> the ops, but Steve Grubb seems to think it would be less; it may be > >> time to look at that a bit more seriously, but if it gets a NACK > >> regardless it isn't worth the time - thoughts? > >> > >> case IORING_OP_OPENAT: > >> audit_uring_entry(req->opcode); > >> ret = io_openat(req, issue_flags); > >> audit_uring_exit(!ret, ret); > >> break; > > > > I wanted to pose this question again in case it was lost in the > > thread, I suspect this may be the last option before we have to "fix" > > things at the Kconfig level. I definitely don't want to have to go > > that route, and I suspect most everyone on this thread feels the same, > > so I'm hopeful we can find a solution that is begrudgingly acceptable > > to both groups. > > May work for me, but have to ask how many, and what is the > criteria? I'd think anything opening a file or manipulating fs: > > IORING_OP_ACCEPT, IORING_OP_CONNECT, IORING_OP_OPENAT[2], > IORING_OP_RENAMEAT, IORING_OP_UNLINKAT, IORING_OP_SHUTDOWN, > IORING_OP_FILES_UPDATE > + coming mkdirat and others. > > IORING_OP_CLOSE? IORING_OP_SEND IORING_OP_RECV? > > What about? > IORING_OP_FSYNC, IORING_OP_SYNC_FILE_RANGE, > IORING_OP_FALLOCATE, IORING_OP_STATX, > IORING_OP_FADVISE, IORING_OP_MADVISE, > IORING_OP_EPOLL_CTL Looking quickly at v5.13-rc4 the following seems like candidates for auditing, there may be a small number of subtractions/additions to this list as people take a closer look, but it should serve as a starting point: IORING_OP_SENDMSG IORING_OP_RECVMSG IORING_OP_ACCEPT IORING_OP_CONNECT IORING_OP_FALLOCATE IORING_OP_OPENAT IORING_OP_CLOSE IORING_OP_MADVISE IORING_OP_OPENAT2 IORING_OP_SHUTDOWN IORING_OP_RENAMEAT IORING_OP_UNLINKAT ... can you live with that list? > Another question, io_uring may exercise asynchronous paths, > i.e. io_issue_sqe() returns before requests completes. > Shouldn't be the case for open/etc at the moment, but was that > considered? Yes, I noticed that when testing the code (and it makes sense when you look at how io_uring handles things). Depending on the state of the system when the io_uring request is submitted I've seen both sync and async io_uring operations with the associated different calling contexts. In the case where io_issue_sqe() needs to defer the operation to a different context you will see an audit record indicating that the operation failed and then another audit record when it completes; it's actually pretty interesting to be able to see how the system and io_uring are working. We could always mask out these delayed attempts, but at this early stage they are helpful, and they may be useful for admins. > I don't see it happening, but would prefer to keep it open > async reimplementation in a distant future. Does audit sleep? The only place in the audit_uring_entry()/audit_uring_exit() code path that could sleep at present is the call to audit_log_uring() which is made when the rules dictate that an audit record be generated. The offending code is an allocation in audit_log_uring() which is currently GFP_KERNEL but really should be GFP_ATOMIC, or similar. It was a copy-n-paste from the similar syscall function where GFP_KERNEL is appropriate due to the calling context at the end of the syscall. I'll change that as soon as I'm done with this email. Of course if you are calling io_uring_enter(2), or something similar, then audit may sleep as part of the normal syscall processing (as mentioned above), but that is due to the fact that io_uring_enter(2) is a syscall and not because of anything in io_issue_sqe(). -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit