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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id D2457C678D5 for ; Wed, 8 Mar 2023 15:51:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678290682; 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=yAER+jucwPUfPz0HRcEezEdRrmTH2urxSZ3Xb64QyQ0=; b=Y6os7MZLbW7yNYm9S0A88Lwnsd1TiONdvnToh6NZglH7OktI0J6j9EQaSDDw04H7sSObrA md1nY0UIGhsWi4fAyotKw8lncYPCmZmZMe9aEotiBJurDvbKACkW1l5kIKZpKZv7/uw/Gw 3egkJyb45Z4ohk+UYBFd7TgQX4MO2/4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-370-2-daZLciMNOKGabUf11icA-1; Wed, 08 Mar 2023 10:51:19 -0500 X-MC-Unique: 2-daZLciMNOKGabUf11icA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2F24885CCE5; Wed, 8 Mar 2023 15:51:17 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id DBEF840C83B6; Wed, 8 Mar 2023 15:51:14 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 9D72E19465B7; Wed, 8 Mar 2023 15:51:14 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 2F30C19465B7 for ; Wed, 8 Mar 2023 15:51:14 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 238192026D2A; Wed, 8 Mar 2023 15:51:14 +0000 (UTC) Received: from x2.localnet (unknown [10.22.33.190]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CEBB72026D76; Wed, 8 Mar 2023 15:51:13 +0000 (UTC) From: Steve Grubb To: Paul Moore , linux-audit@redhat.com Subject: Re: Key based rate limiter (audit_set_rate_limit) Date: Wed, 08 Mar 2023 10:51:13 -0500 Message-ID: <2878938.e9J7NaK4W3@x2> Organization: Red Hat In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux-audit@redhat.com Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wednesday, March 8, 2023 6:53:39 AM EST Anurag Aggarwal wrote: > > Limiting of audit records is actually done in the kernel, and > > currently the rate limit applies equally[1] to all records, there is > > no ability to enforce limits per-key. > > One question Paul, will it be ok, if we contribute something similar to the > Auditd Kernel repository? I'm not Paul...but I think what you are proposing is a per rule service class. Always and best effort where best effort gets discarded when the backlog is above some heuristic. And rules not saying anything are assumed always for backwards compatibility. The main issue is that rules are defined here: https://github.com/linux-audit/audit-kernel/blob/main/include/uapi/linux/ audit.h#L510 There just really isn't room to add more thinkgs without some userspace API problem. (This would definitely need a feaure bitmap so user space can make sense of it.) I suppose we could declare some bits in flags to carry this meaning? Anyways, maybe others might chime in to say if they want/need such a feature. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit