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.129.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 C4C51C433EF for ; Tue, 7 Jun 2022 15:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654614137; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=WvWCLPClsmHyYWJK4MfE+gEznDLgaSFlWybY7o8jDVw=; b=IB8MytuSHcwZHWF1SAm9sh4mVNPrR2HQ+FPCkcrWCT0rdwslGdLxhIEW/ii+UAku0moQ4a Gxwf+YFeA0A8gueN0hWAf3Ehu2Ep2sV71Lu+adxK4HvciJp4L59rom1P4o4jGGX/5oPTg6 /3TCFkdFjtlrHVB0iHBFKZc6i+6Mc40= 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-331-oWn0D_9vPKm5SYz7ijoc6g-1; Tue, 07 Jun 2022 11:02:15 -0400 X-MC-Unique: oWn0D_9vPKm5SYz7ijoc6g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6266B100BABE; Tue, 7 Jun 2022 15:02:12 +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 0056B40D2962; Tue, 7 Jun 2022 15:02:10 +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 C83721947B83; Tue, 7 Jun 2022 15:02:10 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id E3EA219452D2 for ; Tue, 7 Jun 2022 15:02:08 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id D1DD840D282F; Tue, 7 Jun 2022 15:02:08 +0000 (UTC) Received: from x2.localnet (unknown [10.22.17.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A153A40D2827; Tue, 7 Jun 2022 15:02:08 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com, Paul Moore Subject: Re: Be careful with rules Date: Tue, 07 Jun 2022 11:02:08 -0400 Message-ID: <11997104.O9o76ZdvQC@x2> Organization: Red Hat In-Reply-To: References: <3a65017f-bb2f-9e76-98f9-4302644426be@magitekltd.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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: , Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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 Hello Paul, On Tuesday, June 7, 2022 9:42:06 AM EDT Paul Moore wrote: > On Mon, Jun 6, 2022 at 7:10 PM Lenny Bruzenak wrote: > > I've been told that it is not a potential security problem, and not > > subject to change in the (current) kernel. > > I'm that little birdy that Lenny was talking to off-list so I figured > I would add a quick comment here :) > > As a reminder, elevated privilege is needed to both add/remove/modify > audit rules as well as the loaded SELinux policy (affecting the > validity of the relevant security labels). Also, as Lenny already > mentioned, if an invalid security label is used, the kernel will > notify the admin via the kernel log. Wouldn't it be better if the kernel knew the rule was invalid to return EINVAL so that rule loading stops or becomes an error return from auditctl? A long time ago, there was no way from user space to check a type or a role or an selinux user for validity. Can that be done now? Is there an API for it? -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit