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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 1881CC47089 for ; Wed, 26 May 2021 15:49:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E4DEA613D4 for ; Wed, 26 May 2021 15:49:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234553AbhEZPvV (ORCPT ); Wed, 26 May 2021 11:51:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233819AbhEZPvM (ORCPT ); Wed, 26 May 2021 11:51:12 -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 4A7CEC06175F for ; Wed, 26 May 2021 08:49:29 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id i13so2092470edb.9 for ; Wed, 26 May 2021 08:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nametag.social; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hLvM0qZWdxlY7ci8mQoY0tiiY+8Mcy4oEt5BU4lJ9+k=; b=ggzK6VZhCRLTfWGjQrehiYwZ40mLNPjUpPXzYM3fAeBQPdZa8+CYKZvUBvdcSjODtY mvIVJ1vndejpV9VgryvmHn+T0d26E2VFQyfIVL3qP7lEqiN+aDcBCzkEtaiRdFyJhrsR puSF/5bx+BmzVnFfGPeVMFPbkcyjliw90/8cJBcFUO8DKNJsNGJsPRvwkViF0KFVez78 tq0ff/Q5pX86sPp3t6Lc1vmZ2PsOjEISwanl5mLhptQAmNc5JkhosHpCQGDhvpUdLJ6i auNnJvr0TbO1RGGf/lr8KlaIAj5yG70+sSrjfpO9g1P63hWkvLYodX7pdF3ByP2OP6gi p+Fw== 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=hLvM0qZWdxlY7ci8mQoY0tiiY+8Mcy4oEt5BU4lJ9+k=; b=AiccCm/A0xo9BfFHXSnKuDMmGn0EjasFbp1kIBfyg/pd9+9HSXVPGZVXl2C9WzGc2l /prk3b27OiiEnu8qL/bcX9f40SzVM0qErhSkvLokAvRSdRTPpUATie77VdNxtG/wcQWx h2a8Nihsboq9XSYRa8KU5kg288oMITxdsSxc30x3zivdrloo6lbIvhWNTcMb4dUVVA6i XaZhu9u3DQT0lEywUPbMygqyMO5mjT9ulOF626kAuaFqR4iCdMuBno+eMvMBy/KUIR5A 9TdRzgmy2ZNJzWPH0kIklCW8C8kHY36pUbW9Y53Cgg+LnsNq4qjaUdjNCosC2pkvIbxl VB1A== X-Gm-Message-State: AOAM5315gnU9kmh+wdvme9RaflZ4kl2IIFHIt1NvhZiRFjqiwfHkeV9E ObufkM5vQQD2GNrhSCqX/EcKrkfHjAUvHnZ5KdJzvG/w/oLPRA== X-Google-Smtp-Source: ABdhPJzmgIJFBTXLdZvOp6D/+i59vYx4OZSxpIJQjeaRsrMNn5z0yDJEgqvwU+7tOeA0PSsmkvfxgCH0X7UOQIaFBqg= X-Received: by 2002:aa7:d3c8:: with SMTP id o8mr38038619edr.181.1622044167887; Wed, 26 May 2021 08:49:27 -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> <0a668302-b170-31ce-1651-ddf45f63d02a@gmail.com> <18823c99-7d65-0e6f-d508-a487f1b4b9e7@samba.org> In-Reply-To: <18823c99-7d65-0e6f-d508-a487f1b4b9e7@samba.org> From: Victor Stewart Date: Wed, 26 May 2021 11:49:16 -0400 Message-ID: Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring To: Stefan Metzmacher Cc: Paul Moore , Pavel Begunkov , Jens Axboe , linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-audit@redhat.com, io-uring , linux-fsdevel@vger.kernel.org, Kumar Kartikeya Dwivedi , Alexander Viro Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org > I'm wondering why it's not enough to have the native auditing just to happen. > > E.g. all (I have checked RECVMSG,SENDMSG,SEND and CONNECT) socket related io_uring opcodes > already go via security_socket_{recvmsg,sendmsg,connect}() > > IORING_OP_OPENAT* goes via do_filp_open() which is in common with the open[at[2]]() syscalls > and should also trigger audit_inode() and security_file_open(). > > So why is there anything special needed for io_uring (now that the native worker threads are used)? > > 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... stefan's points crossed my mind as well. but assuming iouring buy-in is required, from a design perspective, rather than inserting these audit conditionals in the hotpath, wouldn't a layering model work better? aka enabling auditing changes the function entry point into io_uring and passes operations through an auditing layer, then back to the main entry point. then there is no cost to audit disabled code, and you just force audit to pay whatever double processing cost that entails. V 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 D954CC47082 for ; Wed, 26 May 2021 15:53:43 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 5FD44613D4 for ; Wed, 26 May 2021 15:53:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FD44613D4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=nametag.social 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-528-CQYGE7ezOE2qevgKYQpX9g-1; Wed, 26 May 2021 11:53:40 -0400 X-MC-Unique: CQYGE7ezOE2qevgKYQpX9g-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 B850F800D62; Wed, 26 May 2021 15:53:37 +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 831BB60C5A; Wed, 26 May 2021 15:53:37 +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 01286180B463; Wed, 26 May 2021 15:53:37 +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 14QFnYLr006575 for ; Wed, 26 May 2021 11:49:35 -0400 Received: by smtp.corp.redhat.com (Postfix) id A14357C4D; Wed, 26 May 2021 15:49:34 +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 9CA527C44 for ; Wed, 26 May 2021 15:49:32 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.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 049BF80D0E2 for ; Wed, 26 May 2021 15:49:32 +0000 (UTC) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-559-CtALiQTpPlygDakRRtWCtQ-1; Wed, 26 May 2021 11:49:29 -0400 X-MC-Unique: CtALiQTpPlygDakRRtWCtQ-1 Received: by mail-ed1-f45.google.com with SMTP id s6so2084391edu.10 for ; Wed, 26 May 2021 08:49:28 -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=hLvM0qZWdxlY7ci8mQoY0tiiY+8Mcy4oEt5BU4lJ9+k=; b=LBcbXj3hpyigK5bu6G5rbcKit8mu5dN1nzqrtlSQJAEhwAdr1VbiHK4r0X8aLwj8TB 03MhpTU/9xK90mbn6jbRgt4Dg6dDjKNsWUt/AZ+uXTyg13vmHSEEIX1EEWxGg1BNNJQh Xk0ken74wVD/xsMi3hcLG/EYNk7uHYTjPW7Cj7rc2K2QJ96z8Sb3pbcpY7y482devQUA pe8VPjmiNVLOpONgHPmNNZ9CmEbRzIncFRv2Dadqfii+TrWsd93BDEGcgXo4nz6E7ZWi WGUdnCIifFL/9FZd01WUx/j49gDDxh1rVr/kk6qq7yO27acqi6aEYtiq01h2y8tKysmD Vc1Q== X-Gm-Message-State: AOAM5303f4/1ecsHOW4xgsZw5EeJesQnAKEfJws8mtr5SrEJmn8q71dz ON43o6YxewiJcIL+nkzmXQDu+PKAN1UnU3mK+luemA== X-Google-Smtp-Source: ABdhPJzmgIJFBTXLdZvOp6D/+i59vYx4OZSxpIJQjeaRsrMNn5z0yDJEgqvwU+7tOeA0PSsmkvfxgCH0X7UOQIaFBqg= X-Received: by 2002:aa7:d3c8:: with SMTP id o8mr38038619edr.181.1622044167887; Wed, 26 May 2021 08:49:27 -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> <0a668302-b170-31ce-1651-ddf45f63d02a@gmail.com> <18823c99-7d65-0e6f-d508-a487f1b4b9e7@samba.org> In-Reply-To: <18823c99-7d65-0e6f-d508-a487f1b4b9e7@samba.org> From: Victor Stewart Date: Wed, 26 May 2021 11:49:16 -0400 Message-ID: Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring To: Stefan Metzmacher 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 X-Mailman-Approved-At: Wed, 26 May 2021 11:53:22 -0400 Cc: Jens Axboe , selinux@vger.kernel.org, io-uring , 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I'm wondering why it's not enough to have the native auditing just to happen. > > E.g. all (I have checked RECVMSG,SENDMSG,SEND and CONNECT) socket related io_uring opcodes > already go via security_socket_{recvmsg,sendmsg,connect}() > > IORING_OP_OPENAT* goes via do_filp_open() which is in common with the open[at[2]]() syscalls > and should also trigger audit_inode() and security_file_open(). > > So why is there anything special needed for io_uring (now that the native worker threads are used)? > > 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... stefan's points crossed my mind as well. but assuming iouring buy-in is required, from a design perspective, rather than inserting these audit conditionals in the hotpath, wouldn't a layering model work better? aka enabling auditing changes the function entry point into io_uring and passes operations through an auditing layer, then back to the main entry point. then there is no cost to audit disabled code, and you just force audit to pay whatever double processing cost that entails. V -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit