From patchwork Fri Dec 8 15:51:12 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: 13485586 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="r9i1atS3" Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB3EF10EB for ; Fri, 8 Dec 2023 07:51:27 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5d749e4fa3dso27570817b3.1 for ; Fri, 08 Dec 2023 07:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702050687; x=1702655487; 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=Ek4iMLWDzL7LoVtnCxavodpFayCowS6V3LxbhgEzngA=; b=r9i1atS3BSzpt/n8lAyaZQrcWlFgf/MjxNqfCNKtiXtyypMyqHdbxA39QOqJqF/AFd S3OJj9+x2uwXJ5yBb5Y+S4wFSjKAa7U8jrqC5WV/rno72r9SM/ofb/FVIleur1etKI9a N8brs4fsHarFxBGuVayfxdkw/g+436+lG9GqLTTbG0sk+maTv8kDLjF0A72YBqQGUDUE s7tnIdSrPuJ1zz41qxjoiAnkBBALAMBroU+1mJmxj+QiR5MhiFdZnx3sd/rDaQU05N7S 20c6QJj6NanW8x7XIJ+RgGTzJ9AQKGF7H/TsBsoBTT4Cn7emFTmC6RQ0ADdH6UKbyQvV w7Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702050687; x=1702655487; 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=Ek4iMLWDzL7LoVtnCxavodpFayCowS6V3LxbhgEzngA=; b=tuNBF1ZXPpb3kShPsXWJdK6uRLe7qvD/T0O9/GXBrzHiSB2gau5mjJ15ghJRIPzpca d0RzEmOBpIQLCRDV3U5hHaThmWBvcCTzclXhP7368ySvQtRTV04pQrN2RgV+jZuWmomS PHWKyUVNhOBm/+eEMemYVOqTdqMOK/iW+97GaoX+FdeFpHHUST0e7MNtVKkrBV2s6eMd aUWQ5wNQwxN0sTX2mcGXv10PHYb0iL7JruKs1xv9Eh2lcYvpQrpsMKnY5kcvgI9DisAR P4w0kv3KyOrxLtv3+xIUmE8Mr/IGftLoWwiorRF5jx5xzGvN/PBA9IH3j07oAhFOqAHJ Tf9w== X-Gm-Message-State: AOJu0Yx9s5CKxnm7oGKqNLfPHx+Sd34fNzy0b6Hf0UgBpTbfVEfKkoUE MvH9sfmPZn/CJUDxvaiWJ66byNR5qOjTDDGHb1oUfliJjJ0S1UUbgbfydq6Z0GZQ9HnTZAWPa4j 1sf7IAjdSPQ2ec72oTZuhe2fwQoPEEJ7L+Z2HISkKAzx0zSFctvmXpv2gnxlnuvzCAIGOQmeSvp X+5l2mcw== X-Google-Smtp-Source: AGHT+IF8aR6QmzbJzNsUAkek5pspKQqf/3NnWjMB12JKyovCq9Yc+l+6KkVLim17yptnf6nD/mr1rlzbbvk= X-Received: from sport.zrh.corp.google.com ([2a00:79e0:9d:4:d80e:bfc8:2891:24c1]) (user=gnoack job=sendgmr) by 2002:a05:690c:e18:b0:5d4:1846:3124 with SMTP id cp24-20020a05690c0e1800b005d418463124mr2045ywb.10.1702050686445; Fri, 08 Dec 2023 07:51:26 -0800 (PST) Date: Fri, 8 Dec 2023 16:51:12 +0100 Message-Id: <20231208155121.1943775-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.472.g3155946c3a-goog Subject: [PATCH v8 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