From patchwork Fri Nov 24 17:30:17 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: 13468064 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uj8DOVZH" Received: from mail-ej1-x64a.google.com (mail-ej1-x64a.google.com [IPv6:2a00:1450:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 864FA19A6 for ; Fri, 24 Nov 2023 09:30:32 -0800 (PST) Received: by mail-ej1-x64a.google.com with SMTP id a640c23a62f3a-a00dd93a5f1so158816466b.2 for ; Fri, 24 Nov 2023 09:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700847031; x=1701451831; 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=QMUelqnCSqo6KRVLh7s5ZAoEVkX1RMH2Y99dtswzmhM=; b=uj8DOVZHDJB0Qe/6n1lwH2pU5HFwxkPJVIUOmxEE3jzs6/EjK89cYznDqtSqyrTt2D h0AzBjR3eX0OC7DeRrTxMPfLkoBfO14gFg4S6Z0uypRIkCLibC1JNsCOejuVE0byoREk B6opAZeUPiqhrUt9+2E9ocic1TGVwfUzKBIxQo/aoWEeEqI2VOjWG+M7sbYBcElvN+Wt L9rQAf4ARVvoKDpYaCOYWHFQbTEJT5h25aIIgUyE/Hb5UeMb8v8hCuHsLBCzjYOhgXfM eD6bdhw/oNZZiStpDIcRlbbppZbqh0buDJKxoKJ1iJ3Y8X6wHph3ioOsxGDYi7G2ZoTb HqJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700847031; x=1701451831; 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=QMUelqnCSqo6KRVLh7s5ZAoEVkX1RMH2Y99dtswzmhM=; b=XBfPcaDAKNevbJXC/OZAzDiAlCK1qU1z39L7WBoiqcw43xFd1ndj0BUbdRiQgghGxa UsGsGd3644zt0ScZwwH2snfLnQ+gKO/iJQoowQpVHJ83oGPnqH0v7mZEzywklZ1Cl4Bt QE5Yhu1DnfL41EqryP71a1kK+MTuWt8rAqH6DWnHMpDqjhr1nhS6415NjJGEvf2zmqUx jJRTScNPeGj+Hqv//YAyWsPbuIIvukYSWrLdTr557c/HJY6cDRwF4lCcN8CG6x52SBNE LMk/okdXfO25q64zrjzzSFCy4Ze0jwnrcLuObWHbjcLo6oAm9oO+gW7zWoi/PhDiTiqe AWUg== X-Gm-Message-State: AOJu0YztSl1n0njmP2qwu0LsAQJlg50Mzb3anWILJihGNAZ5jBD5uheA CdYr4D/emdgs7SHa1R4gRyc8Hqb55qnTUYVUjHvE3vXcbkQ40mFpIG919G1VpzizyCzj24f1qQL Ixqyk00qE3a6+5MN+1NJ+N4YXj/6fcO3oackVHEYna5JLqAlXWrjf+hEAE2jn+KOw3Rs1GNGn8x Idb3Agtw== X-Google-Smtp-Source: AGHT+IFsfsjSFUEZ1fHWO9C7fXAf1ECDZJTReTIrE2pEWp+1SuI9BiD6rb+XKzW7svsIhTdn8bNmwx1jeP4= X-Received: from sport.zrh.corp.google.com ([2a00:79e0:9d:4:9429:6eed:3418:ad8a]) (user=gnoack job=sendgmr) by 2002:a05:6402:254d:b0:542:d5b2:a6c9 with SMTP id l13-20020a056402254d00b00542d5b2a6c9mr52250edb.0.1700847030981; Fri, 24 Nov 2023 09:30:30 -0800 (PST) Date: Fri, 24 Nov 2023 18:30:17 +0100 Message-Id: <20231124173026.3257122-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.rc1.413.gea7ed67945-goog Subject: [PATCH v6 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