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 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 B5DD2C04FF3 for ; Mon, 24 May 2021 19:59:42 +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 1A352613E1 for ; Mon, 24 May 2021 19:59:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A352613E1 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-281-tITx9ZElMVG2ABCBJMUNLA-1; Mon, 24 May 2021 15:59:39 -0400 X-MC-Unique: tITx9ZElMVG2ABCBJMUNLA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA0AD501F4; Mon, 24 May 2021 19:59:35 +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 74E521001281; Mon, 24 May 2021 19:59:34 +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 C5DB41800FFC; Mon, 24 May 2021 19:59:32 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 14OJxUxa025442 for ; Mon, 24 May 2021 15:59:30 -0400 Received: by smtp.corp.redhat.com (Postfix) id B87C9200CD5D; Mon, 24 May 2021 19:59:30 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B3E0C2155C4F for ; Mon, 24 May 2021 19:59:28 +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 1E87D1825064 for ; Mon, 24 May 2021 19:59:28 +0000 (UTC) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-470-Gc4h5q6kMAKdZ5fDPlA2dg-1; Mon, 24 May 2021 15:59:23 -0400 X-MC-Unique: Gc4h5q6kMAKdZ5fDPlA2dg-1 Received: by mail-ej1-f50.google.com with SMTP id s22so43413671ejv.12 for ; Mon, 24 May 2021 12:59:22 -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=09wkFCImo62hLXHkPnzCDHAYLxWzFwtrCMOPgJlSi80=; b=UNUalW+tcZrmHTvpJgkzXtcZ3cP8J5T4QyLXq6q9XZEy91YhQab5+0nmp+2fwi0rr/ b06kqYJulPesVqCOqZP78IE0T4GzBAy1XLQQ5FPWpqse5niyE/mCekKQ8PPCiamBnLZL jv5yTdwHtT0iEvOVCxwoiUP6rZxIe+lky1B2AXdhcASy9frWpokS5CpGcE86PXJU5GCv LaxZeyX7/26FNVhvgGI7TYciXq2vWA+N14fhFcuUQG/2BIjAjpIK7wZ9sL4KMEUEXnTp PTHzZIwWaj+Ar/xvnx8OhjMICFlyviqkYCZEQT5Aq8r2mZ4EN4wBcwj+4RqLnx4vUO8x CbRw== X-Gm-Message-State: AOAM532zUf+Bjfs3ecnore5+Lp7Gveu9HVxCqONdgoK550w1DqkmlweG f+J9aeDZM7qicpRMCK8DYoM9pRJ6O3Sl3JZO04FB X-Google-Smtp-Source: ABdhPJyJnn8cTuWE0D6WCTdnxc3zkrXdZltcoobyaH7I8DthDbUf1aZItUpXKY/gO3bnHsam4ng+oV2h/jNU1sQt9pA= X-Received: by 2002:a17:907:10d8:: with SMTP id rv24mr24731654ejb.542.1621886361736; Mon, 24 May 2021 12:59:21 -0700 (PDT) MIME-Version: 1.0 References: <162163367115.8379.8459012634106035341.stgit@sifl> <162163379461.8379.9691291608621179559.stgit@sifl> <162219f9-7844-0c78-388f-9b5c06557d06@gmail.com> In-Reply-To: <162219f9-7844-0c78-388f-9b5c06557d06@gmail.com> From: Paul Moore Date: Mon, 24 May 2021 15:59:10 -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.6 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.84 on 10.5.11.22 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 Sun, May 23, 2021 at 4:26 PM Pavel Begunkov wrote: > On 5/22/21 3:36 AM, Paul Moore wrote: > > On Fri, May 21, 2021 at 8:22 PM Pavel Begunkov wrote: > >> On 5/21/21 10:49 PM, Paul Moore wrote: > [...] > >>> > >>> + 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. > > It is always true at this point, would be completely broken > otherwise Understood, I was just pointing out an oddity in the code. I just dropped the checks from my local tree, you'll see it in the next draft of the patchset. > >> 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. > > Who knows. First of all, seems CONFIG_AUDIT is enabled by default > for many popular distributions, so I assume that is not compiled out. > > What are use cases for audit? Always running I guess? Audit has been around for quite some time now, and it's goal is to provide a mechanism for logging "security relevant" information in such a way that it meets the needs of various security certification efforts. Traditional Linux event logging, e.g. syslog and the like, does not meet these requirements and changing them would likely affect the usability for those who are not required to be compliant with these security certifications. The Linux audit subsystem allows Linux to be used in places it couldn't be used otherwise (or rather makes it a *lot* easier). That said, audit is not for everyone, and we have build time and runtime options to help make life easier. Beyond simply disabling audit at compile time a number of Linux distributions effectively shortcut audit at runtime by adding a "never" rule to the audit filter, for example: % auditctl -a task,never > Putting aside compatibility problems, it sounds that with the amount of overhead > it adds there is no much profit in using io_uring in the first place. > Is that so? Well, if audit alone erased all of the io_uring advantages we should just rip io_uring out of the kernel and people can just disable audit instead ;) I believe there are people who would like to use io_uring and are also required to use a kernel with audit, either due to the need to run a distribution kernel or the need to capture security information in the audit stream. I'm hoping that we can find a solution for these users; if we don't we are asking this group to choose either io_uring or audit, and that is something I would like to avoid. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit