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: 13475906 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 600F610F4 for ; Fri, 1 Dec 2023 06:30:49 -0800 (PST) Received: by mail-ed1-x54a.google.com with SMTP id 4fb4d7f45d1cf-542fe446d45so1594143a12.0 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=QLIRMrgyHuGGTzoV8YztsYKVn1Sfxr2Gylb984SMgZnQKV9XeBYKphdss+GUvbD0tI Z0cO6fXRnTAm3umwZAE775dA5Yl5duucipBS0xFn2DsSdtW9shCkfE5UbQ6eX0eqWnGF 9c9By+Uuy7it2fH6/eF/HI9FcFcCCBId2lAv/Mwmo0CQnCBmEDJDcB3g7SfIT1dG/J3i syAWpwrNkD3O9zod/x5u5o2lm+6E3N3txQ8MRgF6m+dmxclCx4RQJcfoXZ2prGCRX9h8 oDCWG0hgK8GBF5xSkzhhooGglup0EC438IkKu0Tm78uoAOw/GGagtSaep7H3O4guefSv XnCw== X-Gm-Message-State: AOJu0Yz67GLrUTFLz8W1hAYWNiOxjEPFnN5sqHpwL3zKKGMZMz4Nb5Xv 3+it7LhhIlVCURLC3cS9B1xhkHe0AyUWKzWIXJsRLntjtIDIc+SiiaZ0T1X1I73RRtKR29VZw1N mO+3HpSDa8072kW9t4YklFWMf/mY3tLBtZcMhJYqfXBnEh4q3fPsAV5xTGZb9PRWo3izkaCbAeF AD44Oofw== 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-security-module@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