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=-7.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 63518C47089 for ; Thu, 27 May 2021 17:27:35 +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 0EF8E6128B for ; Thu, 27 May 2021 17:27:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EF8E6128B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622136454; 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=0tJhV7jNoJZiH1tkZBhTumVcONP56LzD82gUSIhi69k=; b=JlSHJN0ci7hVPXW+hn1xF2NpPOH68ZG3aHlkA/ryDmJhKPj4baF8TRc0MgQRQE6fjOBsrs mRANjDa524b4QhHAQYOCGR+qYYpxNHra0mUbWCLU45Hee+gHCy4k6rxxwGASBdUNWMKvGX 7Q6mKscHTMk0P4i0mpZAOx6osFwRh6I= 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-261-cdmja1JSPgWYXU7yBxlT0w-1; Thu, 27 May 2021 13:27:32 -0400 X-MC-Unique: cdmja1JSPgWYXU7yBxlT0w-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7CD6D8042CB; Thu, 27 May 2021 17:27:28 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AA5CB60864; Thu, 27 May 2021 17:27:26 +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 F063755348; Thu, 27 May 2021 17:27:23 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 14RHRLO3012685 for ; Thu, 27 May 2021 13:27:21 -0400 Received: by smtp.corp.redhat.com (Postfix) id 4216A5D9C6; Thu, 27 May 2021 17:27:21 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.3.128.13]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 43DE75D9DC; Thu, 27 May 2021 17:27:10 +0000 (UTC) Date: Thu, 27 May 2021 13:27:07 -0400 From: Richard Guy Briggs To: Jens Axboe Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring Message-ID: <20210527172707.GI2268484@madcap2.tricolour.ca> References: <162219f9-7844-0c78-388f-9b5c06557d06@gmail.com> <8943629d-3c69-3529-ca79-d7f8e2c60c16@kernel.dk> <0a668302-b170-31ce-1651-ddf45f63d02a@gmail.com> <18823c99-7d65-0e6f-d508-a487f1b4b9e7@samba.org> <20210526154905.GJ447005@madcap2.tricolour.ca> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-loop: linux-audit@redhat.com Cc: selinux@vger.kernel.org, io-uring@vger.kernel.org, Stefan Metzmacher , linux-security-module@vger.kernel.org, linux-audit@redhat.com, Kumar Kartikeya Dwivedi , linux-fsdevel@vger.kernel.org, Pavel Begunkov , 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.13 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-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 2021-05-26 11:22, Jens Axboe wrote: > On 5/26/21 9:49 AM, Richard Guy Briggs wrote: > >> So why is there anything special needed for io_uring (now that the > >> native worker threads are used)? > > > > Because syscall has been bypassed by a memory-mapped work queue. > > I don't follow this one at all, that's just the delivery mechanism if > you choose to use SQPOLL. If you do, then a thread sibling of the > original task does the actual system call. There's no magic involved > there, and the tasks are related. > > So care to expand on that? These may be poor examples, but hear me out... In the case of an open call, I'm guessing that they are mapped 1:1 syscall to io_uring action so that the action can be asynchronous. So in this case, there is a record of the action, but we don't see the result success/failure. I assume that file paths can only be specified in the original syscall and not in an SQPOLL action? In the case of a syscall read/write (which aren't as interesting generally to audit, but I'm concerned there are other similar situations that are), the syscall would be called for every buffer that is passed back and forth user/kernel and vice versa, providing a way to log all that activity. In the case of SQPOLL, I understand that a syscall sets up the action and then io_uring takes over and does the bulk transfer and we'd not have the visibility of how many times that action was repeated nor that the result success/failure was due to its asynchrony. Perhaps I am showing my ignorance, so please correct me if I have it wrong. > >> Is there really any io_uring opcode that bypasses the security checks the corresponding native syscall > >> would do? If so, I think that should just be fixed... > > > > This is by design to speed it up. This is what Paul's iouring entry and > > exit hooks do. > > As far as I can tell, we're doing double logging at that point, if the > syscall helper does the audit as well. We'll get something logging the > io_uring opcode (eg IORING_OP_OPENAT2), then log again when we call the > fs helper. That's _assuming_ that we always hit the logging part when we > call into the vfs, but that's something that can be updated to be true > and kept an eye on for future additions. > > Why is the double logging useful? It only tells you that the invocation > was via io_uring as the delivery mechanism rather than the usual system > call, but the effect is the same - the file is opened, for example. > > I feel like I'm missing something here, or the other side is. Or both! Paul addressed this in his reply, but let me add a more concrete example... There was one corner case I was looking at that showed up this issue. Please indicate if I have mischaracterized or misunderstood. A syscall would generate records something like this: AUDIT_SYSCALL AUDIT_... AUDIT_EOE A io_uring SQPOLL event would generate something like this: AUDIT_URINGOP AUDIT_... AUDIT_EOE The "hybrid" event that is a syscall that starts an io_uring action would generate something like this: AUDIT_URINGOP [possible AUDIT_CONFIG_CHANGE (from killed_trees)] AUDIT_SYSCALL AUDIT_... AUDIT_EOE The AUDIT_... is all the operation-specific records that log parameters that aren't able to be expressed in the SYSLOG or URINGOP records such as pathnames, other arguments, and context (pwd, etc...). So this isn't "double logging". It is either introducing an io_uring event, or it is providing more detail about the io_uring arguments to a syscall event. > Jens Axboe - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit