From patchwork Fri Dec 1 14:30:33 2023 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: 13475896 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="n8U2i/g7" Received: from mail-ed1-x54a.google.com (mail-ed1-x54a.google.com [IPv6:2a00:1450:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DD9B10F3 for ; Fri, 1 Dec 2023 06:30:49 -0800 (PST) Received: by mail-ed1-x54a.google.com with SMTP id 4fb4d7f45d1cf-54c64c3a702so316433a12.2 for ; Fri, 01 Dec 2023 06:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701441048; x=1702045848; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:mime-version :message-id:date:from:to:cc:subject:date:message-id:reply-to; bh=MTiOWpw4mbkI96jmZgH9ZmDtOQJP3/Ahm+uC5ZzVjrM=; b=n8U2i/g7CT10tAwZEQpSwy624XtxPeTrj5RUc68kV0GAonpxLy4Q2LHynmN8JCiUKp c9c1EXRNvCfWM2eB9Om37AvHQAZGTFnoCoGdpK+PhiQ5zNQGNeF8QdCddzJNPfq6Pz3Z WK6MRE9T7msh+76N7Dn4YHEJhK4/xjoj411s91akJNEHIUypYS07oUYcbwu763OAAONm KlMfTT5mVShWS6CefhCuY9fuG83evs9MRskoXoQ3hq8gk1XYj8u2G73SjUj2MPLKyFjn ngMWkYhOo5UD7HjTfoL/j3bjtsGuNhXexr+9yMZH+t0klo2berqqwR3go6Fg51qy0jnq bpYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701441048; x=1702045848; h=content-transfer-encoding:cc:to:from:subject:mime-version :message-id:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MTiOWpw4mbkI96jmZgH9ZmDtOQJP3/Ahm+uC5ZzVjrM=; b=dfrBLbqFpcATqL/eZY/5gd+H36bGyCN1VCkUNXKPN1SCtw6ScidHCWoEzIel26/BTp DzmlLkpfsr7IEQXHdfVBeQATdGVSOuhynPSfOegWhAKbuA7QEcOyorJf8eou7OJEsQto NjR9uYa1RBiHl0XgszZ2idOQJAbi4XQhyvtACuONs73GUSrpYz9EnXrLzccie3u4jsjS QmniO181VAIpXwBq2nk3KUx6CcMcvaQmSjLH75WDhgG+AU1tHnSWBROmODMu51lZKdMJ e6e7u0SYm3U9WMMNa5a8p4oSBx/GpfUQ73jw6YkCjBd1jNqeAnz8Drwz6O9m3RWG7nPL nHOQ== X-Gm-Message-State: AOJu0YytBUhc9M3CdoUVzajROYAzQx/QeyiXRlF2DSrAY3k0fhZElwrA XXEBwPGCi4Dvd2ceG2yMHZxc+U16vE0= X-Google-Smtp-Source: AGHT+IFYO6JUpM7k4TfyBZNVtswNPipkHnhHiz77cFn+HElXwWFH0HXL7VF0tMP2B4wxW4YNc3n6NoSt7Lc= X-Received: from sport.zrh.corp.google.com ([2a00:79e0:9d:4:fab0:4182:b9df:bfec]) (user=gnoack job=sendgmr) by 2002:a05:6402:1bc7:b0:54c:5e07:ea3 with SMTP id ch7-20020a0564021bc700b0054c5e070ea3mr19596edb.5.1701441047533; Fri, 01 Dec 2023 06:30:47 -0800 (PST) Date: Fri, 1 Dec 2023 15:30:33 +0100 Message-Id: <20231201143042.3276833-1-gnoack@google.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.43.0.rc2.451.g8631bc7472-goog Subject: [PATCH v7 0/9] Landlock: 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 , 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?= " Hello! These patches add simple ioctl(2) support to Landlock. Objective ~~~~~~~~~ Make ioctl(2) requests restrictable with Landlock, in a way that is useful for real-world applications. Proposed approach ~~~~~~~~~~~~~~~~~ Introduce the LANDLOCK_ACCESS_FS_IOCTL right, which restricts the use of ioctl(2) on file descriptors. We attach IOCTL access rights to opened file descriptors, as we already do for LANDLOCK_ACCESS_FS_TRUNCATE. If LANDLOCK_ACCESS_FS_IOCTL is handled (restricted in the ruleset), the LANDLOCK_ACCESS_FS_IOCTL access right governs the use of all IOCTL commands. We make an exception for the common and known-harmless IOCTL commands FIOCLEX, FIONCLEX, FIONBIO and FIONREAD. These IOCTL commands are always permitted. Their functionality is already available through fcntl(2). If additionally(!), the access rights LANDLOCK_ACCESS_FS_READ_FILE, LANDLOCK_ACCESS_FS_WRITE_FILE or LANDLOCK_ACCESS_FS_READ_DIR are handled, these access rights also unlock some IOCTL commands which are considered safe for use with files opened in these ways. As soon as these access rights are handled, the affected IOCTL commands can not be permitted through LANDLOCK_ACCESS_FS_IOCTL any more, but only be permitted through the respective more specific access rights. A full list of these access rights is listed below in this cover letter and in the documentation. I believe that this approach works for the majority of use cases, and offers a good trade-off between Landlock API and implementation complexity and flexibility when the feature is used. Current limitations ~~~~~~~~~~~~~~~~~~~ With this patch set, ioctl(2) requests can *not* be filtered based on file type, device number (dev_t) or on the ioctl(2) request number. On the initial RFC patch set [1], we have reached consensus to start with this simpler coarse-grained approach, and build additional IOCTL restriction capabilities on top in subsequent steps. [1] https://lore.kernel.org/linux-security-module/d4f1395c-d2d4-1860-3a02-2a0c023dd761@digikod.net/ Notable implications of this approach ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Existing inherited file descriptors stay unaffected when a program enables Landlock. This means in particular that in common scenarios, the terminal's IOCTLs (ioctl_tty(2)) continue to work. * ioctl(2) continues to be available for file descriptors acquired through means other than open(2). Example: Network sockets, memfd_create(2), file descriptors that are already open before the Landlock ruleset is enabled. Examples ~~~~~~~~ Starting a sandboxed shell from $HOME with samples/landlock/sandboxer: LL_FS_RO=/ LL_FS_RW=. ./sandboxer /bin/bash The LANDLOCK_ACCESS_FS_IOCTL right is part of the "read-write" rights here, so we expect that newly opened files outside of $HOME don't work with most IOCTL commands. * "stty" works: It probes terminal properties * "stty