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: 13468050 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-ed1-x549.google.com (mail-ed1-x549.google.com [IPv6:2a00:1450:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60FEF19A5 for ; Fri, 24 Nov 2023 09:30:32 -0800 (PST) Received: by mail-ed1-x549.google.com with SMTP id 4fb4d7f45d1cf-5488298dd1eso1261062a12.1 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=IlyUyp+X6qJpwbBZ+jQ5tocRBR4sJwKptHUfGQ3z6eYeUQlbV/MFOp+DYfYerR6aDv omA8xXHEmZbahPHieapH+ke73i4paiZiUrFZTBOnkBGA73UGKozyCdM3EB98mY6gTTty ug+UI2xe9xEBAP/CR4xW78715rlvrpTXZTzrGZE86jjxNz98FkXkyMVCZYVWzdmSwB4N wugAEQnXTyPCzEKFArHO4r8/AVssALUeF3ssDFl/g6kGLezV8RmDRGI+xJXS2mYEPwtH fJKsHlgF4KfinAKZnlcn8z3YWylF142ZZNzL42CmwyMlCycV/q/4IppxtmTSbSu8tCH8 qcKg== X-Gm-Message-State: AOJu0YxZyRsZTHTVAuYRPj8ZkUrp5LLdx2I7UVoLjIV8JK/BULvUF+uI sdqe9V4X5yQV4u/Z8GueJ3iPB3z8E6Q= 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-fsdevel@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