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 EC65CC7EE24 for ; Tue, 30 May 2023 18:06:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231389AbjE3SGO (ORCPT ); Tue, 30 May 2023 14:06:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232558AbjE3SGM (ORCPT ); Tue, 30 May 2023 14:06:12 -0400 Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B7ADA1 for ; Tue, 30 May 2023 11:06:11 -0700 (PDT) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-19f7e8f8e3bso891521fac.3 for ; Tue, 30 May 2023 11:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1685469970; x=1688061970; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=p7WRh4ii68vVijZcHEibAPvhm7wB3t2DgvK1gWdbP0w=; b=SR6CZIAZ5SrMXVefyj6q4AWjVzk+3nx5ztjEYVIDzHaQlSWPlZLLJS3fKnd20JH3af XgTNLL0sKfPaQHVad3CXjU9BxRXsrG1DsnWejL5KS5V95z6R5dH7MsxnXhJlk/1ztLRh eWK2KR/Mer2KgvCMxN8lVOTO0jKfjrdKUqPT4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685469970; x=1688061970; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p7WRh4ii68vVijZcHEibAPvhm7wB3t2DgvK1gWdbP0w=; b=ReZC30ix1VvW5dceNdyZ4AQlCUP/+i6q+kFD+u5DVTNxwLzn4sQAicGFAIWpDeSzhe vdbINa2ThWcTPtW6+nyejmk1i4AlbQh/pUmVsnfkVVza278Oh/Q/gCRQWB8Ie/c3Aw5f TpMQ+3Vil+vdWMFTCSPUnssaqkYREuSQsDJsOZ9gXhrht43eVHcX61FObhFqoimMrwlu /Buyf/ObqcPA+6aM6V1xlfhbMiQuCIGrO9aBshTVEZXauf/wy7oZqyaxGIyH8TgLlUOZ kaouLSMkPKM9lyYYoDMLpfu2tzPnCv79RKDwophfX6FMsQSJH9MNZzosA7O+uRcYa1BZ JGrw== X-Gm-Message-State: AC+VfDwaMULPHwuaTef4Yc5wyoZj7QKAeyYZiclwn/yav2+xKVIxiXkp ZkGrJ66hJvO+99mpC8GdsDAgZyniDpz+NwljfWFz8Q== X-Google-Smtp-Source: ACHHUZ7qfBuWJ7g/cUNl+4SloyhS1Jw/vsZzM5+CPBT1v63IbYJcCNJUmCOE72tByfzCCQdV4OnJwFRtxt2hx6Ct028= X-Received: by 2002:a05:6871:c10d:b0:196:87c5:8881 with SMTP id yq13-20020a056871c10d00b0019687c58881mr1376299oab.10.1685469970177; Tue, 30 May 2023 11:06:10 -0700 (PDT) MIME-Version: 1.0 References: <20230518204549.3139044-1-enlightened@chromium.org> <1225a567-4ff5-462e-0db6-1a88a748d787@digikod.net> In-Reply-To: From: Jeff Xu Date: Tue, 30 May 2023 11:05:00 -0700 Message-ID: Subject: Re: [PATCH v2] lsm: adds process attribute getter for Landlock To: Casey Schaufler Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Paul Moore , Shervin Oloumi , linux-security-module@vger.kernel.org, jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org, allenwebb@chromium.org, gnoack3000@gmail.com, areber@redhat.com, criu@openvz.org, linux-api@vger.kernel.org, jannh@google.com, brauner@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: On Thu, May 25, 2023 at 9:28=E2=80=AFAM Casey Schaufler wrote: > > On 5/24/2023 9:02 AM, Micka=C3=ABl Sala=C3=BCn wrote: > > > > On 24/05/2023 17:38, Micka=C3=ABl Sala=C3=BCn wrote: > >> > >> On 23/05/2023 23:12, Paul Moore wrote: > >>> On Tue, May 23, 2023 at 2:13=E2=80=AFAM Jeff Xu = wrote: > >>>> On Mon, May 22, 2023 at 12:56=E2=80=AFPM Paul Moore > >>>> wrote: > >>>>> On Thu, May 18, 2023 at 5:26=E2=80=AFPM Casey Schaufler > >>>>> wrote: > >>>>>> On 5/18/2023 1:45 PM, Shervin Oloumi wrote: > >>>>>>> Adds a new getprocattr hook function to the Landlock LSM, which > >>>>>>> tracks > >>>>>>> the landlocked state of the process. This is invoked when > >>>>>>> user-space > >>>>>>> reads /proc/[pid]/attr/domain > >>>>>> > >>>>>> Please don't add a Landlock specific entry directly in the attr/ > >>>>>> directory. Add it only to attr/landlock. > >>>>>> > >>>>>> Also be aware that the LSM maintainer (Paul Moore) wants to move > >>>>>> away from the /proc/.../attr interfaces in favor of a new system > >>>>>> call, > >>>>>> which is in review. > >>>>> > >>>>> What Casey said above. > >>>>> > >>>>> There is still some uncertainty around timing, and if we're perfect= ly > >>>>> honest, acceptance of the new syscalls at the Linus level, but yes,= I > >>>>> would very much like to see the LSM infrastructure move away from > >>>>> procfs and towards a syscall API. Part of the reasoning is that th= e > >>>>> current procfs API is ill-suited to handle the multiple, stacked LS= Ms > >>>>> and the other part being the complexity of procfs in a namespaced > >>>>> system. If the syscall API is ultimately rejected, we will need to > >>>>> revisit the idea of a procfs API, but even then I think we'll need = to > >>>>> make some changes to the current approach. > >>>>> > >>>>> As I believe we are in the latter stages of review for the syscall > >>>>> API, perhaps you could take a look and ensure that the current > >>>>> proposed API works for what you are envisioning with Landlock? > >> > >> I agree, and since the LSM syscalls are almost ready that should not > >> change much the timing. In fact, extending these syscalls might be > >> easier than tweaking the current procfs/attr API for Landlock specific > >> requirements (e.g. scoped visibility). We should ensure that these > >> syscalls would be a good fit to return file descriptors, but in the > >> short term we only need to know if a process is landlocked or not, so = a > >> raw return value (0 or -errno) will be enough. > >> > >> Mentioning in the LSM syscalls patch series that they may deal with (a= nd > >> return) file descriptors could help API reviewers though. > > > > It should be kept in mind that the current LSM syscalls only deal with > > the calling task, whereas the goal of this Landlock patch series is to > > inspect other tasks. A new LSM syscall would need to be created to > > handle pidfd e.g., named lsm_get_proc_attr() or lsm_get_pid_attr(). > > I think it would be lsm_get_pid_attr(). Yes, it's the obvious next step. > > > > > I'm not sure if this should be a generic LSM syscall or a Landlock > > syscall though. I have plan to handle processes other than the caller > > (e.g. to restrict an existing process hierarchy), so thinking about a > > Landlock-specific syscall could make sense. > > > > To summarize, creating a new LSM syscall to deal with pidfd and to get > > LSM process "status/attr" looks OK. However, Landlock-specific > > syscalls to deal with Landlock specificities (e.g. ruleset or domain > > file descriptor) make more sense. > > > > Having one LSM-generic syscall to get minimal Landlock attributes > > (i.e. mainly to know if a process is sandboxed), and another > > Landlock-specific syscall to do more things (e.g. get the domain file > > descriptor, restrict a task) seems reasonable. The second one would > > overlap with the first one though. What do you think? > > I find it difficult to think of a file descriptor as an attribute of > a process. To my (somewhat unorthodox) thinking a file descriptor is > a name for an object, not an attribute of the object. You can't access > an object by its attributes, but you can by its name. An attribute is > a description of the object. I'm perfectly happy with lsm_get_pid_attr() > returning an attribute that is a file descriptor if it describes the > process in some way, but not as a substitute for opening /proc/42. > > If I understand correctly: 1> A new lsm syscall - lsm_get_pid_attr(): Landlock will return the process's landlock sandbox status: true/false. Is this a right fit for SELinux to also return the process's enforcing mode ? such as enforcing/permissive. 2> Landlock will have its own specific syscall to deal with Landlock specificities (e.g. ruleset or domain file descriptor).