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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1A3AE7E64C for ; Tue, 26 Sep 2023 16:24:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235290AbjIZQYq (ORCPT ); Tue, 26 Sep 2023 12:24:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235280AbjIZQYo (ORCPT ); Tue, 26 Sep 2023 12:24:44 -0400 Received: from mail-ej1-x649.google.com (mail-ej1-x649.google.com [IPv6:2a00:1450:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 398939F for ; Tue, 26 Sep 2023 09:24:37 -0700 (PDT) Received: by mail-ej1-x649.google.com with SMTP id a640c23a62f3a-993eeb3a950so772589166b.2 for ; Tue, 26 Sep 2023 09:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695745475; x=1696350275; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:from:to:cc:subject:date :message-id:reply-to; bh=vFkpn2H397KrVSqmEDJx57x47TGFCVVPTN7FsnVWNzE=; b=1hFoAxEOGZbiAoDfKUO45fdAWUEnVPrTBLwCnAr5TndUi/CpxBn4N2Vq1G7Cor+nrS TlakioOk9Tsthn2A54LcuTsp8JDA2B4qaImYYhJ8y8tJv2k705Z349CfRgjJkCFso9b/ ihC9g1f0pzKXY/pbEy5j6vbvMVfaG4BDrS0R1cZPB5r5fSeaGnaoPEbVxr/SYTQmZcex M+u2H29QOgUKN2lbH5joPfQMlQazTm9aYcB9SF0Dgn8t8EL5jQSumXFzt2ExdyR04+g4 zvUYFoT2XN5GNc8iPiQQv0BDq1LmY60xhNJyYnGij0FXmQZ7+wtrVOdnYJ+5KsoK/Ehx /cmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695745475; x=1696350275; h=content-transfer-encoding:cc:to:from:subject:references :mime-version:message-id:in-reply-to:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=vFkpn2H397KrVSqmEDJx57x47TGFCVVPTN7FsnVWNzE=; b=v2otWTOXUj7C3SAahVf/f0Nt+Icm4EEbp7tAzTVl+gBSxVs3RCUnn+EK0f7B8xU7OR ZRmIoI/U/ERYRcoBq/B1Y/cz2bbHhwWulQuAliYMyVMplra1PbNT06cJJU7/YZDjpmoa CV7H1FIvHSfcs+7vTQu3/6isedOyb2IRb8LY5v6yKXjMxmHjkjVkKXpJ2Cp/2DdaxFyM XlxM91fk4EphlGISzTlq4yxbgGutjW1+8IPbuRXWtzFVrZf0TYVRY8NxQUNllw1bx8ZZ YKqCHcBGh28KYiiHca66AmRu0SvzBHr0z6oAB5qPIuKQnUq8Yy1UM8dbMI/KYwBdKuNa lwyg== X-Gm-Message-State: AOJu0YxrlTaMq5KBsthkELi+lhvtsxFSAupd5KTbOCJsY2mKKX7PytLq DZ1AB8btFsvstC08WOfTstZVajfd/u8= X-Google-Smtp-Source: AGHT+IHBoakqhkhiVEAsv+mZQ0hK5/qDN1CmFMFNKuR5J4mjx2CZrD8PGaR7oJWeHShb9Petn58MPj8g4wE= X-Received: from sport.zrh.corp.google.com ([2a00:79e0:9d:4:dc99:dac4:b719:7cd8]) (user=gnoack job=sendgmr) by 2002:a17:907:7110:b0:9a1:b087:3bcb with SMTP id zr16-20020a170907711000b009a1b0873bcbmr34230ejb.7.1695745475433; Tue, 26 Sep 2023 09:24:35 -0700 (PDT) Date: Tue, 26 Sep 2023 18:24:32 +0200 In-Reply-To: <20230921061641.273654-1-mic@digikod.net> Message-Id: Mime-Version: 1.0 References: <20230921061641.273654-1-mic@digikod.net> Subject: Re: [RFC PATCH v1 0/7] Landlock audit support From: "=?iso-8859-1?Q?G=FCnther?= Noack" To: "=?iso-8859-1?Q?Micka=EBl_Sala=FCn?=" Cc: Eric Paris , James Morris , Paul Moore , "Serge E . Hallyn" , Ben Scarlato , Jeff Xu , Jorge Lucangeli Obes , Konstantin Meskhidze , Shervin Oloumi , audit@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: Hi Micka=C3=ABl! On Thu, Sep 21, 2023 at 08:16:34AM +0200, Micka=C3=ABl Sala=C3=BCn wrote: > This patch series adds basic audit support to Landlock for most actions. > Logging denied requests is useful for different use cases: > * app developers: to ease and speed up sandboxing support > * power users: to understand denials > * sysadmins: to look for users' issues > * tailored distro maintainers: to get usage metrics from their fleet > * security experts: to detect attack attempts >=20 > To make logs useful, they need to contain the most relevant Landlock > domain that denied an action, and the reason. This translates to the > latest nested domain and the related missing access rights. Is "domain" always the latest nested domain, or is that the domain which ca= used the check to fail because it denied the requested access right? (If it is = just the counter of how many domains are stacked, this could maybe also be queri= ed through proc instead?) > Two "Landlock permissions" are used to describe mandatory restrictions > enforced on all domains: > * fs_layout: change the view of filesystem with mount operations. > * ptrace: tamper with a process. I find the term "access" already a bit overloaded, and the term "permission= " also already appears in other contexts. Maybe we can avoid the additional terminology by grouping these two together in the log format, and calling t= hem the "cause" or "reason" for the deny decision? In a sense, the access righ= ts and the other permissions can already be told apart by their names, so they might also both appear under the same key without causing additional confus= ion? > Here is an example of logs, result of the sandboxer activity: > tid=3D267 comm=3D"sandboxer" op=3Dcreate-ruleset ruleset=3D1 handled_acce= ss_fs=3Dexecute,write_file,read_file,read_dir,remove_dir,remove_file,make_c= har,make_dir,make_reg,make_sock,make_fifo,make_block,make_sym,refer,truncat= e > tid=3D267 comm=3D"sandboxer" op=3Drestrict-self domain=3D2 ruleset=3D1 pa= rent=3D0 > op=3Drelease-ruleset ruleset=3D1 > tid=3D267 comm=3D"bash" domain=3D2 op=3Dopen errno=3D13 missing-fs-access= es=3Dwrite_file,read_file missing-permission=3D path=3D"/dev/tty" dev=3D"de= vtmpfs" ino=3D9 > tid=3D268 comm=3D"ls" domain=3D2 op=3Dopen errno=3D13 missing-fs-accesses= =3Dread_dir missing-permission=3D path=3D"/" dev=3D"vda2" ino=3D256 > tid=3D269 comm=3D"touch" domain=3D2 op=3Dmknod errno=3D13 missing-fs-acce= sses=3Dmake_reg missing-permission=3D path=3D"/" dev=3D"vda2" ino=3D256 > tid=3D270 comm=3D"umount" domain=3D2 op=3Dumount errno=3D1 missing-fs-acc= esses=3D missing-permission=3Dfs_layout name=3D"/" dev=3D"tmpfs" ino=3D1 > tid=3D271 comm=3D"strace" domain=3D2 op=3Dptrace errno=3D1 missing-fs-acc= esses=3D missing-permission=3Dptrace opid=3D1 ocomm=3D"systemd" In more complicated cases like "refer" and "open", it is possible that more= than one access right is missing, and presumably they'll both be listed in missing-fs-accesses=3D. In this case, it is not clear to me whether the do= main=3D number is referring to the first or the second of these missing rights. (Assuming that the domain=3D is about the domain which caused the denial.) > As highlighted in comments, support for audit is not complete yet with > this series: some actions are not logged (e.g. file reparenting), and > rule additions are not logged neither. When ftruncate(2) gets denied, it is also not possible to tell which of the nested domains is responsible, without additional changes to what we carry around in the file's security blob. (Right now, we calculate the overall truncation right in advance at open(2) time, and just store that bit with t= he newly opened file.) > I'm also not sure if we need to have seccomp-like features such as > SECCOMP_FILTER_FLAG_LOG, SECCOMP_RET_LOG, and > /proc/sys/kernel/seccomp/actions_logged >=20 > I'd like to get some early feedback on this proposal. If you want to have the full feature set as proposed above for other operat= ions as well, like file reparenting and truncation, it'll complicate the Landloc= k logic and increase the amount of data that needs to be kept around just for logging. I'm not convinced that this is worth it. After all, the simpler = the Landlock implementation is, the easier it'll be to reason about its logic a= nd its security guarantees. A possible simplification would be to omit the domain number which is responsible for a "deny" decision. I feel that for debugging, knowing the = fact that Landlock denied an operation might already be a big step forward, and = the exact domain responsible for it might not be that important? =E2=80=94G=C3=BCnther --=20 Sent using Mutt =F0=9F=90=95 Woof Woof