From patchwork Sat Mar 9 07:53:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?G=C3=BCnther_Noack?= X-Patchwork-Id: 13587515 X-Patchwork-Delegate: paul@paul-moore.com Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7DE5376F4 for ; Sat, 9 Mar 2024 07:53:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709970829; cv=none; b=X2vbtev2l67gMC6U7yzcHjJNtGKVucFQxumuiqH+JVsR8SvIPVeODFwMZgDEOvi7z6MNvce96/ZKTJK9SSsxO6nMomUcJtbZ2ipPdZs6WQeUO1xjLIA3kX2LNCk9L4+0asH46h6C1/eO5qzSVo9XWLQ3RMl3QXbVtHm3RpcPr2Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709970829; c=relaxed/simple; bh=iNASLIvdJe+G6gv4UkYZwtV4xslMi/uxI/J6OfYzLr4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=BW4rm7fv3pDgov68HXuVkyLsLkzvjlLDcFHb0HzU3Kvhbpx1Me/cORYzv7sIvt7ex48SZRjsuS9lL6MZ+UFgHWpJ2i/eyoFHZeqXX3pun2gmk6+3hsG1WtGkxbCEvNIh2lphB85CokBSK9CHwcWag/KwBfb+kA8iq45+GzEEhVU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--gnoack.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=a9lEBZjN; arc=none smtp.client-ip=209.85.208.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--gnoack.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="a9lEBZjN" Received: by mail-ed1-f73.google.com with SMTP id 4fb4d7f45d1cf-56813bb5e6eso1107407a12.3 for ; Fri, 08 Mar 2024 23:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709970826; x=1710575626; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=6xXJZ8Luy05jNZz1hxoLS/0EOiBPDRz4nsKqPpejmYo=; b=a9lEBZjNLqLYqxlfU6QcctJoL42PqqBJG/wKXQqzvuPWkiZYDQlW4OKg4gcJcch5OF f1eUg7Iz97s9wCTTkO+lyOZZlFom2d5VW2hpgq37yJ/3OQinVK0K/lLlavMhF09mK7ar bmyjupsrq2cQCZvvVUUiF4jkOwHShqLUnCLzf62Q1E0hfdBSsq3Rxt3ZccgM2iVbfQO6 6Rd9hpjoYXNgpKcS/+XZF4FIvgpZ9N/A767hfNfLOaI6RG2HuKYXHoL7FpNwieWn2zn4 VnJxy0mLlcaikWdfEBMqPAnFGREaRjtqLD5WSMu7jOEUJhID68zcabGmlLjgAcDXSonD GlQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709970826; x=1710575626; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=6xXJZ8Luy05jNZz1hxoLS/0EOiBPDRz4nsKqPpejmYo=; b=e/jebKmSSn10ILqZFFOEymsdBWq8qoC9lH48mLS5HAudKwYnmGP1K3w6kZJWXgJWW1 3ki7c5F/acw7cN9+iTusqrMNAZL3yHmvb3arBCRU6u08YiUtaCv/X3b8qNoxFDeWr+Rq UOtJ/tGXFjvDbr6pEgxawg8g6eUtAuCHNZvos1mIEfmWNZYbwRVwvGN83jaa1gLFPNbO hyNPjGTceinkUxYYK6HedQ1lBqpIsbGxSa8V5qCfJ+1e5S1USuIqcP6H3NRRAGd3Ks5m ulfyi33NK8IO/trhLpzu1UXsWzeFyA5f0vqQJbLoW5vlLQo2HbB2URVaWa5P+PlNemX2 wz0g== X-Gm-Message-State: AOJu0YxY0BMIzRf3xpRhFxUC5k8WQSpecVvZ8Z8BN890iXaoyFU/7tNf mFxq95+GY9GJ0C5E2xDf1cbEmURQnYbjuwJTyZa6e/i1PM2j0x/nRL9eWbY9WdVdnuSKyHnkQYN EKedzOHaFfi1ZxJSCIzNKXJfYsxFne+NVth8BT475aqL6a7afbUSK51OdIs74xfVG4wNrZ9IeRD YcpjAcYeoRHMzAha4him6hADu31p+uXqqGn5sL3EWD52Yosks9o28H X-Google-Smtp-Source: AGHT+IEB16Vl/CLO+9oSUIXkxJcIHM6QCLqVnsRZhcK17ONeugIEM3ZuOtBIVdNkYYAcgICZia0DsXcQOBc= X-Received: from swim.c.googlers.com ([fda3:e722:ac3:cc00:31:98fb:c0a8:1605]) (user=gnoack job=sendgmr) by 2002:a05:6402:f0a:b0:566:c465:20cf with SMTP id i10-20020a0564020f0a00b00566c46520cfmr7206eda.1.1709970826003; Fri, 08 Mar 2024 23:53:46 -0800 (PST) Date: Sat, 9 Mar 2024 07:53:20 +0000 In-Reply-To: <20240309075320.160128-1-gnoack@google.com> Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240309075320.160128-1-gnoack@google.com> X-Mailer: git-send-email 2.44.0.278.ge034bb2e1d-goog Message-ID: <20240309075320.160128-10-gnoack@google.com> Subject: [PATCH v10 9/9] landlock: Document IOCTL support From: " =?utf-8?q?G=C3=BCnther_Noack?= " To: linux-security-module@vger.kernel.org, " =?utf-8?q?Micka=C3=ABl_Sala?= =?utf-8?q?=C3=BCn?= " Cc: Jeff Xu , Arnd Bergmann , Jorge Lucangeli Obes , Allen Webb , Dmitry Torokhov , Paul Moore , Konstantin Meskhidze , Matt Bobrowski , linux-fsdevel@vger.kernel.org, " =?utf-8?q?G=C3=BCnther_Noack?= " In the paragraph above the fallback logic, use the shorter phrasing from the landlock(7) man page. Signed-off-by: Günther Noack --- Documentation/userspace-api/landlock.rst | 76 +++++++++++++++++++----- 1 file changed, 61 insertions(+), 15 deletions(-) diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index 838cc27db232..32391247f19a 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -76,7 +76,8 @@ to be explicit about the denied-by-default access rights. LANDLOCK_ACCESS_FS_MAKE_BLOCK | LANDLOCK_ACCESS_FS_MAKE_SYM | LANDLOCK_ACCESS_FS_REFER | - LANDLOCK_ACCESS_FS_TRUNCATE, + LANDLOCK_ACCESS_FS_TRUNCATE | + LANDLOCK_ACCESS_FS_IOCTL_DEV, .handled_access_net = LANDLOCK_ACCESS_NET_BIND_TCP | LANDLOCK_ACCESS_NET_CONNECT_TCP, @@ -85,10 +86,10 @@ to be explicit about the denied-by-default access rights. Because we may not know on which kernel version an application will be executed, it is safer to follow a best-effort security approach. Indeed, we should try to protect users as much as possible whatever the kernel they are -using. To avoid binary enforcement (i.e. either all security features or -none), we can leverage a dedicated Landlock command to get the current version -of the Landlock ABI and adapt the handled accesses. Let's check if we should -remove access rights which are only supported in higher versions of the ABI. +using. + +To be compatible with older Linux versions, we detect the available Landlock ABI +version, and only use the available subset of access rights: .. code-block:: c @@ -114,6 +115,10 @@ remove access rights which are only supported in higher versions of the ABI. ruleset_attr.handled_access_net &= ~(LANDLOCK_ACCESS_NET_BIND_TCP | LANDLOCK_ACCESS_NET_CONNECT_TCP); + __attribute__((fallthrough)); + case 4: + /* Removes LANDLOCK_ACCESS_FS_IOCTL_DEV for ABI < 5 */ + ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_IOCTL_DEV; } This enables to create an inclusive ruleset that will contain our rules. @@ -225,6 +230,7 @@ access rights per directory enables to change the location of such directory without relying on the destination directory access rights (except those that are required for this operation, see ``LANDLOCK_ACCESS_FS_REFER`` documentation). + Having self-sufficient hierarchies also helps to tighten the required access rights to the minimal set of data. This also helps avoid sinkhole directories, i.e. directories where data can be linked to but not linked from. However, @@ -318,18 +324,26 @@ It should also be noted that truncating files does not require the system call, this can also be done through :manpage:`open(2)` with the flags ``O_RDONLY | O_TRUNC``. -When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` -right is associated with the newly created file descriptor and will be used for -subsequent truncation attempts using :manpage:`ftruncate(2)`. The behavior is -similar to opening a file for reading or writing, where permissions are checked -during :manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and +The truncate right is associated with the opened file (see below). + +Rights associated with file descriptors +--------------------------------------- + +When opening a file, the availability of the ``LANDLOCK_ACCESS_FS_TRUNCATE`` and +``LANDLOCK_ACCESS_FS_IOCTL_DEV`` rights is associated with the newly created +file descriptor and will be used for subsequent truncation and ioctl attempts +using :manpage:`ftruncate(2)` and :manpage:`ioctl(2)`. The behavior is similar +to opening a file for reading or writing, where permissions are checked during +:manpage:`open(2)`, but not during the subsequent :manpage:`read(2)` and :manpage:`write(2)` calls. -As a consequence, it is possible to have multiple open file descriptors for the -same file, where one grants the right to truncate the file and the other does -not. It is also possible to pass such file descriptors between processes, -keeping their Landlock properties, even when these processes do not have an -enforced Landlock ruleset. +As a consequence, it is possible that a process has multiple open file +descriptors referring to the same file, but Landlock enforces different things +when operating with these file descriptors. This can happen when a Landlock +ruleset gets enforced and the process keeps file descriptors which were opened +both before and after the enforcement. It is also possible to pass such file +descriptors between processes, keeping their Landlock properties, even when some +of the involved processes do not have an enforced Landlock ruleset. Compatibility ============= @@ -458,6 +472,28 @@ Memory usage Kernel memory allocated to create rulesets is accounted and can be restricted by the Documentation/admin-guide/cgroup-v1/memory.rst. +IOCTL support +------------- + +The ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right restricts the use of +:manpage:`ioctl(2)`, but it only applies to *newly opened* device files. This +means specifically that pre-existing file descriptors like stdin, stdout and +stderr are unaffected. + +Users should be aware that TTY devices have traditionally permitted to control +other processes on the same TTY through the ``TIOCSTI`` and ``TIOCLINUX`` IOCTL +commands. Both of these require ``CAP_SYS_ADMIN`` on modern Linux systems, but +the behavior is configurable for ``TIOCSTI``. + +On older systems, it is therefore recommended to close inherited TTY file +descriptors, or to reopen them from ``/proc/self/fd/*`` without the +``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right, if possible. + +Landlock's IOCTL support is coarse-grained at the moment, but may become more +fine-grained in the future. Until then, users are advised to establish the +guarantees that they need through the file hierarchy, by only allowing the +``LANDLOCK_ACCESS_FS_IOCTL_DEV`` right on files where it is really required. + Previous limitations ==================== @@ -495,6 +531,16 @@ bind and connect actions to only a set of allowed ports thanks to the new ``LANDLOCK_ACCESS_NET_BIND_TCP`` and ``LANDLOCK_ACCESS_NET_CONNECT_TCP`` access rights. +IOCTL (ABI < 5) +--------------- + +IOCTL operations could not be denied before the fifth Landlock ABI, so +:manpage:`ioctl(2)` is always allowed when using a kernel that only supports an +earlier ABI. + +Starting with the Landlock ABI version 5, it is possible to restrict the use of +:manpage:`ioctl(2)` using the new ``LANDLOCK_ACCESS_FS_IOCTL_DEV`` access right. + .. _kernel_support: Kernel support