From patchwork Mon Aug 14 17:28:11 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: 13353149 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 2EFE6C001DB for ; Mon, 14 Aug 2023 17:29:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230293AbjHNR2y (ORCPT ); Mon, 14 Aug 2023 13:28:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230338AbjHNR2n (ORCPT ); Mon, 14 Aug 2023 13:28:43 -0400 Received: from mail-ej1-x649.google.com (mail-ej1-x649.google.com [IPv6:2a00:1450:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B37010DB for ; Mon, 14 Aug 2023 10:28:42 -0700 (PDT) Received: by mail-ej1-x649.google.com with SMTP id a640c23a62f3a-99bdee94b84so583063266b.0 for ; Mon, 14 Aug 2023 10:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692034121; x=1692638921; h=content-transfer-encoding:cc:to:from:subject:mime-version :message-id:date:from:to:cc:subject:date:message-id:reply-to; bh=o5l+QsaLOamdQtdZNWRx5dwfJH2NfNhSil0AGBzNqbQ=; b=Q5WZe9RVvCiT4ur4DrkEfujuE56JtVViIekN0mOsu+Xg4vrE+EsW4M4FEB13hAxGi4 wPbIhxZZGq+ImC/5DYbwZBWUuAFIPIOLfnDfJcWSI/nY97gg8XYcGunqPk4wU6eL5myj NjbwoHIyv1vuuFdzUTxnJ1zUhuc2oNK5/1AAQCYQj2lg1owuBknSYOgTekLgP9TgfjPW puj/0YINzRz/SAQPB8IlLASAo4qNfin9/gHEWrYujLXfHe3xM/H2LKoNA95A+TueqIyy 2dXUh9PyLjWBbJ7x7rE+I00Iu3Ix01Hux3BA5N3tQmNaLw5aQuge0zDnNmsHrnfIxLPJ o4NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692034121; x=1692638921; 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=o5l+QsaLOamdQtdZNWRx5dwfJH2NfNhSil0AGBzNqbQ=; b=bqKOQNiXt1GIucMHYlR2wWtzuydIqN2rcTJkIVgf+HS3SvNRvytSSmY2HPIGKCN188 FC4GIfMTTdChVj6gLVeltYUVjQ1Ee5xWVUXdZgS5yaGvdUHPJ08e7NWkDRHMFCYUfD/m QviJd5jqhPGBHGEyLwKBO0Teb5QwjJGMrC+eV3rtb+Nf3O0sk0yJS8EWWncPJ1N1sHXT zz6JLWx5NsSrKFoTdwx+v6S/isJcU0UA26AFFfKkpkNAQ94Up4At4FkoWdLohjswjm9m fGy5miLvrHBY/4z/btQA03XIp0gfdG8IbGm95IEsM8yTUbPbgtZIA+vqHUjtpBJQvFvN w98w== X-Gm-Message-State: AOJu0YwVx4o/5w3J6id1glLAEbrIoSOWgouN+xB8CMIeaTXv8B0JnB/C Sa1/gYQJJA2U2u+Ea7SwyT8eh62sohOA/3UDdSWkBqLRPj7uhfbP88e27nMp4e5gJGSwiCVYJ9g /+ck/PXb1oDnE6OHsJRcJhWLDVQtt8VbqnLb4mMIOS5ZS2j33PhjdL59md4E4cgGEOE4mHBmrDz k5vGFKjQ== X-Google-Smtp-Source: AGHT+IGWg3IpP0RSlqkJ0MiWjSt+va5EmEZVpaXHnaXupCXQthaUimwM/v7HUlxPMi+qQaA5BEXFBO62RzM= X-Received: from sport.zrh.corp.google.com ([2a00:79e0:9d:4:9ca9:bbb1:765a:e929]) (user=gnoack job=sendgmr) by 2002:a17:907:1622:b0:99b:cb25:3980 with SMTP id hb34-20020a170907162200b0099bcb253980mr105897ejc.2.1692034120668; Mon, 14 Aug 2023 10:28:40 -0700 (PDT) Date: Mon, 14 Aug 2023 19:28:11 +0200 Message-Id: <20230814172816.3907299-1-gnoack@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.41.0.694.ge786442a9b-goog Subject: [PATCH v3 0/5] 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 the LANDLOCK_ACCESS_FS_IOCTL right to opened file descriptors, as we already do for LANDLOCK_ACCESS_FS_TRUNCATE. We make an exception for the common and known-harmless IOCTL commands FIOCLEX, FIONCLEX, FIONBIO, FIOASYNC and FIONREAD. These IOCTL commands are always permitted. The functionality of the first four is already available through fcntl(2), and FIONREAD only returns the number of ready-to-read bytes. 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 ioctl(2). * "stty" works: It probes terminal properties * "stty