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 BAAC3C4707F for ; Wed, 26 May 2021 02:04:45 +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 349B6613C5 for ; Wed, 26 May 2021 02:04:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 349B6613C5 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-507-J-YZzOu-PAaDhRM2kXT4ew-1; Tue, 25 May 2021 22:04:42 -0400 X-MC-Unique: J-YZzOu-PAaDhRM2kXT4ew-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 02909800FF0; Wed, 26 May 2021 02:04:39 +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 56FDD5D6AC; Wed, 26 May 2021 02:04:38 +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 0D6F855348; Wed, 26 May 2021 02:04: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 14Q24YFl024500 for ; Tue, 25 May 2021 22:04:34 -0400 Received: by smtp.corp.redhat.com (Postfix) id 151FFFDCD3; Wed, 26 May 2021 02:04:34 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast04.extmail.prod.ext.rdu2.redhat.com [10.11.55.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0FAC5FDCD4 for ; Wed, 26 May 2021 02:04:31 +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 0E4E4101A531 for ; Wed, 26 May 2021 02:04:31 +0000 (UTC) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-389-OxRql2raPnaS8XYgcCv06A-1; Tue, 25 May 2021 22:04:28 -0400 X-MC-Unique: OxRql2raPnaS8XYgcCv06A-1 Received: by mail-ed1-f47.google.com with SMTP id r11so38517487edt.13 for ; Tue, 25 May 2021 19:04: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=AVDziIe4V6YxS8ijZfxm39fjCEHx8wW3u92rBRAH8wk=; b=QCLkHIPzUnfPo9D2zcOlNLxQniFk1ArJl9j/rg46PWMOd1hfzmeaYM2iDkmaGMS3bj 2PmrCa22v322fOl1thKSHEez7luMysf+qnsKP1uYT28WCWpkW442LKdNQRdDQyYvFGFF KBcBVt7w7nCTaddYypVNT3jfgxuGaNKTeVkaDj7h4rheiCBf47bYkSknj6kYJUO3j6hK Mve0Je4xCgxqCfsBwwx+t86uVPUKL1y3inU3NGhkuad/abseRPvsUQ3FvUJpSfA/2AhD 1Wz0ktPar9dvNce1O63Sf/3iz/pZN9vt50rQyU27Er/1JxOXoWw7au29zfVuhe+vObqO oSFA== X-Gm-Message-State: AOAM530cHb5fRqzFM9cxyVw6uxQTvUohI3Ne0PVWYqBPFcdcdURi17+4 yRGa3b+hhdDqvMpj+kt2t+IJzwOWdREqRWD1erLQ X-Google-Smtp-Source: ABdhPJzLxVYWHyIPDuzmWEqrz4zwzl/MN/HfR7rgSiIG2g2/GNZnsS+o3skTAZzrh5FnnRtatTsqRTZDXToXHCfXJnw= X-Received: by 2002:aa7:c7cd:: with SMTP id o13mr12537237eds.269.1621994667198; Tue, 25 May 2021 19:04: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> In-Reply-To: <8943629d-3c69-3529-ca79-d7f8e2c60c16@kernel.dk> From: Paul Moore Date: Tue, 25 May 2021 22:04:16 -0400 Message-ID: Subject: Re: [RFC PATCH 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring To: Jens Axboe 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: selinux@vger.kernel.org, io-uring@vger.kernel.org, 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.15 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 Tue, May 25, 2021 at 9:11 PM Jens Axboe wrote: > On 5/24/21 1:59 PM, Paul Moore wrote: > > 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 > > As has been brought up, the issue we're facing is that distros have > CONFIG_AUDIT=y and hence the above is the best real world case outside > of people doing custom kernels. My question would then be how much > overhead the above will add, considering it's an entry/exit call per op. > If auditctl is turned off, what is the expectation in turns of overhead? I commented on that case in my last email to Pavel, but I'll try to go over it again in a little more detail. As we discussed earlier in this thread, we can skip the req->opcode check before both the _entry and _exit calls, so we are left with just the bare audit calls in the io_uring code. As the _entry and _exit functions are small, I've copied them and their supporting functions below and I'll try to explain what would happen in CONFIG_AUDIT=y, "task,never" case. + static inline struct audit_context *audit_context(void) + { + return current->audit_context; + } + static inline bool audit_dummy_context(void) + { + void *p = audit_context(); + return !p || *(int *)p; + } + static inline void audit_uring_entry(u8 op) + { + if (unlikely(audit_enabled && audit_context())) + __audit_uring_entry(op); + } We have one if statement where the conditional checks on two individual conditions. The first (audit_enabled) is simply a check to see if anyone has "turned on" auditing at runtime; historically this worked rather well, and still does in a number of places, but ever since systemd has taken to forcing audit on regardless of the admin's audit configuration it is less useful. The second (audit_context()) is a check to see if an audit_context has been allocated for the current task. In the case of "task,never" current->audit_context will be NULL (see audit_alloc()) and the __audit_uring_entry() slowpath will never be called. Worst case here is checking the value of audit_enabled and current->audit_context. Depending on which you think is more likely we can change the order of the check so that the current->audit_context check is first if you feel that is more likely to be NULL than audit_enabled is to be false (it may be that way now). + static inline void audit_uring_exit(int success, long code) + { + if (unlikely(!audit_dummy_context())) + __audit_uring_exit(success, code); + } The exit call is very similar to the entry call, but in the "task,never" case it is very simple as the first check to be performed is the current->audit_context check which we know to be NULL. The __audit_uring_exit() slowpath will never be called. > aio never had any audit logging as far as I can tell. I think it'd make > a lot more sense to selectively enable audit logging only for opcodes > that we care about. File open/create/unlink/mkdir etc, that kind of > thing. File level operations that people would care about logging. Would > they care about logging a buffer registration or a polled read from a > device/file? I highly doubt it, and we don't do that for alternative > methods either. Doesn't really make sense for a lot of the other > operations, imho. We would need to check with the current security requirements (there are distro people on the linux-audit list that keep track of that stuff), but looking at the opcodes right now my gut feeling is that most of the opcodes would be considered "security relevant" so selective auditing might not be that useful in practice. It would definitely clutter the code and increase the chances that new opcodes would not be properly audited when they are merged. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit