From patchwork Fri Nov 17 15:49:13 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: 13459085 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98A79C47071 for ; Fri, 17 Nov 2023 15:49:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231502AbjKQPtg (ORCPT ); Fri, 17 Nov 2023 10:49:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231406AbjKQPtf (ORCPT ); Fri, 17 Nov 2023 10:49:35 -0500 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C4C6B9 for ; Fri, 17 Nov 2023 07:49:31 -0800 (PST) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d9ab7badadeso2857175276.1 for ; Fri, 17 Nov 2023 07:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700236170; x=1700840970; 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=GWzjwemHVnboIvAGDjxXzY657GUx5oZnM/Gu7ZKaHIQ=; b=lmUCtJFf9olJFIQtqTPLeCHEpZd9czIvodLADKZSr1BbqPITi/NkJMFi2fKMI4YSO7 bqYsmh7V1ybGzQEk9+ADD0cCCbjXR8B/dr3Ia5ZQsrOeAVdMZDfzSiBBB2qorx6iqBvU GdXPXmTMqk5Rw17RO+s92zFfbc6xGlPozwNnmqm79daqkRmz8fQ+QLVB2Zx9F6Rv290k 108T46o/iykwViG/eoovdykIZQs6uuumY8NtMyzt0fV68KJRca9KqLkuQgLdGMzNxfDR A9zt8rBHV9wXqKOijgIBxL0FyzzHQMzXiNl0W8xzByIICiHzsmUJguv5svPhtvcX7pdK XuMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700236170; x=1700840970; 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=GWzjwemHVnboIvAGDjxXzY657GUx5oZnM/Gu7ZKaHIQ=; b=a6FKFvVWL8XR4X8de4JgWzzqebDtZxTjPdtCXs2ZPaQe6H0/yeNfG/qCc5/Svqudvj 4/keZo3rc2DERjMcqxwOKcKDC6sfC7tyP5aMcjAdt4kMqDcH81bA9s4aBTpw3zHS2iiF 8ufAuqloUuBe9u+j4Iev3YbXrQmnnkgN1sgQyewcCDKULXKGnfrFark0hzUzfJA8FTPm VvnlBkZIQ0zAUj1zdAahm8Kx6JfNKtHDHipyXeWBe1qntRRhC2cDqHal2zeJnAWUMWO1 wHG2nog1ABYEf2Bt+rVQb5JUfdVLjQkXkIaZBx52rBwu4+xRsqv1GTJq85FtDFkin77s GWxw== X-Gm-Message-State: AOJu0YyuwJZuhkVImPmMMei7IjMtdUEVZkrTjqJDCmr3O0oF9A71DpJX Gm0TZQaX+BZvIGNNombV8QS3f5TCl+d4MCUW9N3ds2Lb05OC3x3c8v9j92t+AeI5lPUtDup9I9+ FHB6/APHO5g5vpvEh4slwvx0gp4nLSniZV6k4s3g8WstbTcofXBnOCKcbZkcR5bQkdu/YtP0gWb GVZ981EQ== X-Google-Smtp-Source: AGHT+IG8N06sNWEAwsciTDeTJSXl7GG6VCv8pn/6vMdz/sg2CymlKqAzK4WCzrKJajC39uqhSJsU7MN0zBI= X-Received: from sport.zrh.corp.google.com ([2a00:79e0:9d:4:2ae5:2882:889e:d0cf]) (user=gnoack job=sendgmr) by 2002:a25:d7c4:0:b0:d9a:4f4c:961b with SMTP id o187-20020a25d7c4000000b00d9a4f4c961bmr463055ybg.1.1700236170109; Fri, 17 Nov 2023 07:49:30 -0800 (PST) Date: Fri, 17 Nov 2023 16:49:13 +0100 Message-Id: <20231117154920.1706371-1-gnoack@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.43.0.rc0.421.g78406f8d94-goog Subject: [PATCH v5 0/7] 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?= " Precedence: bulk List-ID: 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