From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C731FC2BA2B for ; Wed, 8 Apr 2020 16:24:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A1F0820784 for ; Wed, 8 Apr 2020 16:24:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="DsqtBI6q" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729939AbgDHQYr (ORCPT ); Wed, 8 Apr 2020 12:24:47 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:44800 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730279AbgDHQYr (ORCPT ); Wed, 8 Apr 2020 12:24:47 -0400 Received: by mail-lj1-f193.google.com with SMTP id z26so4162609ljz.11 for ; Wed, 08 Apr 2020 09:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s5aiANvhgix2N64LwK7RWDgOwJhQeHsVBzrYi29ys94=; b=DsqtBI6qRFjNpPkePJmA4uX3kNk0ar1H6f+mDa9WCWCogbW1T44w59UgWS3voTEzVK genV1UO4Or0H2X/qb8IDbOA88OBquO3BkpRlNYz06H9TiREZObOBBJUBZTq+Ufv9WsE4 +7C0iZS1MYYzD1pJn+M2c6GEdXyXvNHvkqSWB4XXDBcfiYWq+U6RNTMgvedFjt69dE17 14nDpSBj3rkurQYjwNYAGpRsn6UJpZ2eN0cavWpSULcVrBGXx1iDEO77FjTZcDVdSRvX QkJmuqfyrMbk+hWYW2pBub6BYirXJ+pM+Mp0JbV/YyhrzUF5+jieHm0nw0AYVfNnXrxV gdfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s5aiANvhgix2N64LwK7RWDgOwJhQeHsVBzrYi29ys94=; b=Ecbb26qirxiy5p0Yf+3O0UvMX9EvBY5lugFxEoTl6ZhyqeRqp6VzHi43RPULOeoy3x Jthqsd+jtAzqtP5jHywqq8F0efpz9n11QH6fvZ2EWsrMjr1lKu7vDR6uLCnVny2gM6YF JTX6Gu0SXdJAM/EsuAO0NfL1XgNZkjzZiaPe5HsLkXhVzeQMNgGlKH1G44bMgIxVYlUc TAAq8Qf99zo2jVBCUeoWC0kIY7trw6I2R3MGJ9VKRmMgPCLB71UZnNy27tYYG3Ne5uqi tNPLKmCfbjAItjgzf1/jBc5RK3Vi1AoAhdKm/lHMNBJVEJ94TMwx5v8VwEmoDZ9ecKUl 6XxQ== X-Gm-Message-State: AGi0PuagxJCS3CfkKOnEv72fcX5njOYQ5hSSut5DNDCMz+01g0xtA9eQ mU+9mzAZag3wTCmAleooGBVdF06kHPJ2PMtwGW9lrQ== X-Google-Smtp-Source: APiQypJwZtEyXK5GJK6816AgkQZ1Cx5TsDhHg1RPi2SPIJaChvEwYWQCWwAp1ip6qeVHQ0/Dbzy1kvzvsVWhJz83qlI= X-Received: by 2002:a05:651c:287:: with SMTP id b7mr400146ljo.73.1586363083460; Wed, 08 Apr 2020 09:24:43 -0700 (PDT) MIME-Version: 1.0 References: <20200408152151.5780-1-christian.brauner@ubuntu.com> In-Reply-To: <20200408152151.5780-1-christian.brauner@ubuntu.com> From: Jann Horn Date: Wed, 8 Apr 2020 18:24:16 +0200 Message-ID: Subject: Re: [PATCH 0/8] loopfs To: Christian Brauner Cc: Jens Axboe , Greg Kroah-Hartman , kernel list , linux-block@vger.kernel.org, Linux API , Jonathan Corbet , Serge Hallyn , "Rafael J. Wysocki" , Tejun Heo , "David S. Miller" , Saravana Kannan , Jan Kara , David Howells , Seth Forshee , David Rheinsberg , Tom Gundersen , Christian Kellner , Dmitry Vyukov , =?UTF-8?Q?St=C3=A9phane_Graber?= , linux-doc@vger.kernel.org, Network Development , Matthew Garrett , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Wed, Apr 8, 2020 at 5:23 PM Christian Brauner wrote: > One of the use-cases for loopfs is to allow to dynamically allocate loop > devices in sandboxed workloads without exposing /dev or > /dev/loop-control to the workload in question and without having to > implement a complex and also racy protocol to send around file > descriptors for loop devices. With loopfs each mount is a new instance, > i.e. loop devices created in one loopfs instance are independent of any > loop devices created in another loopfs instance. This allows > sufficiently privileged tools to have their own private stash of loop > device instances. Dmitry has expressed his desire to use this for > syzkaller in a private discussion. And various parties that want to use > it are Cced here too. > > In addition, the loopfs filesystem can be mounted by user namespace root > and is thus suitable for use in containers. Combined with syscall > interception this makes it possible to securely delegate mounting of > images on loop devices, i.e. when a user calls mount -o loop > it will be possible to completely setup the loop device. > The final mount syscall to actually perform the mount will be handled > through syscall interception and be performed by a sufficiently > privileged process. Syscall interception is already supported through a > new seccomp feature we implemented in [1] and extended in [2] and is > actively used in production workloads. The additional loopfs work will > be used there and in various other workloads too. You'll find a short > illustration how this works with syscall interception below in [4]. Would that privileged process then allow you to mount your filesystem images with things like ext4? As far as I know, the filesystem maintainers don't generally consider "untrusted filesystem image" to be a strongly enforced security boundary; and worse, if an attacker has access to a loop device from which something like ext4 is mounted, things like "struct ext4_dir_entry_2" will effectively be in shared memory, and an attacker can trivially bypass e.g. ext4_check_dir_entry(). At the moment, that's not a huge problem (for anything other than kernel lockdown) because only root normally has access to loop devices. Ubuntu carries an out-of-tree patch that afaik blocks the shared memory thing: But even with that patch, I'm not super excited about exposing filesystem image parsing attack surface to containers unless you run the filesystem in a sandboxed environment (at which point you don't need a loop device anymore either).