From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-bc0a.mail.infomaniak.ch (smtp-bc0a.mail.infomaniak.ch [45.157.188.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78B2E1DE3B5 for ; Thu, 16 Jan 2025 10:57:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737025050; cv=none; b=VfjcP8dULgUkVMVNj/U/+5EErWrxzviaBCJhqddAwfQiMvbS9MisXiYTVJE2xhAjroVG50B2Pvd9DfMDdllUHV7T7IKYdPAwbQzn8f5T4ZYU/IT8f+WJssGo2J41yrcfs94gx4ZG1J79zNudX1aHXOEme5LjitGSQFVHdTq/fGs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737025050; c=relaxed/simple; bh=VQ20OYCm7LTW6QnWoDw/BkUofW5RRIhojQ1mEuKiVAg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SdEEkMAmYaATY6233O5veoqsiLRoJCUm0Oc9q0fe28eUdm715PNmDU9k53I9n1WdFBQIlhU3DN0u8G4Dt4yVXR427qoUooMueyx3fmIEC8uL7c2nlxYPcjcwC+Pr0KBH/DeWxDtK54TkY1cZUZ9rWSs0U+F8EMQ1phJi972u9Xg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=kF3N5X6P; arc=none smtp.client-ip=45.157.188.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="kF3N5X6P" Received: from smtp-3-0000.mail.infomaniak.ch (unknown [IPv6:2001:1600:4:17::246b]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4YYfvg5vPBznM1; Thu, 16 Jan 2025 11:57:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1737025039; bh=gTDiyaTDPfpSnRlUFP5GvbzzGcDbaMRsUAaVHeyXyFg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kF3N5X6PYIa/hs4bz66HeXt7oGXMwmBDiyi6tqwX3PM+UaeoDl72WzyjccazmlWom lY0PObCTTDVq8/KJBDsuFwgnljF4ktnYou0Kgy3smjcv0DGWN2ASsB6Q5DjclI6cZ7 vh/dvENtCQ5BBb+oVBjVfeoTNWtrAKlaxD0QlNTU= Received: from unknown by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4YYfvf25pYz1s3; Thu, 16 Jan 2025 11:57:18 +0100 (CET) Date: Thu, 16 Jan 2025 11:57:17 +0100 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Paul Moore Cc: Eric Paris , =?utf-8?Q?G=C3=BCnther?= Noack , "Serge E . Hallyn" , Ben Scarlato , Casey Schaufler , Charles Zaffery , Daniel Burgener , Francis Laniel , James Morris , Jann Horn , Jeff Xu , Jorge Lucangeli Obes , Kees Cook , Konstantin Meskhidze , Matt Bobrowski , Mikhail Ivanov , Phil Sutter , Praveen K Paladugu , Robert Salvet , Shervin Oloumi , Song Liu , Tahera Fahimi , Tyler Hicks , audit@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v4 28/30] audit,landlock: Add AUDIT_EXE_LANDLOCK_DENY rule type Message-ID: <20250116.tie4PhauzooC@digikod.net> References: <20250108154338.1129069-29-mic@digikod.net> <1ac8548a7b42eaed3f4392690011eb8b@paul-moore.com> Precedence: bulk X-Mailing-List: audit@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1ac8548a7b42eaed3f4392690011eb8b@paul-moore.com> X-Infomaniak-Routing: alpha On Wed, Jan 15, 2025 at 06:53:08PM -0500, Paul Moore wrote: > On Jan 8, 2025 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= wrote: > > > > Landlock manages a set of standalone security policies, which can be > > loaded by any process. Because a sandbox policy may contain errors and > > can lead to log spam, we need a way to exclude some of them. It is > > simple and it makes sense to identify Landlock domains (i.e. security > > policies) per binary path that loaded such policy. > > > > Add a new AUDIT_EXE_LANDLOCK_DENY rule type to enables system > > administrator to filter logs according to the origin or the security > > policy responsible for a denial. > > For reasons similar to why I didn't want to expose the audit timestamp > to users outside of audit, I'm not very enthusiastic about expanding > the audit filtering code at this point in time. > > I'm not saying "no" exactly, just "not right now". Contrary to MAC systems which are configured and tuned by one entity (e.g. the sysadmin), Landlock security policies can be configured by a lot of different entities (e.g. sysadmin, app developers, users). One noisy policy (e.g. a buggy sandboxed tar called in a loop by maintenance scripts) could easily flood the audit logs without the ability for sysadmins to filter such policy. They will only be able to filter all users that *may* trigger such log (by executing the buggy sandboxed app), which would mean almost all users, which would mask all other legitimate Landlock events, then nullifying the entire audit support for Landlock. My plan was to extend these new kind of filter types to PID, UID, GID, and LOGINUID (a subset of the audit filter exclude list) to give the necessary flexibility to filter policy creators. We really need a way to filter policy creators, and that needs to be part of the (initial) Landlock audit support for it to be viable. What do you propose?