From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756144AbaIWRDu (ORCPT ); Tue, 23 Sep 2014 13:03:50 -0400 Received: from mail-qa0-f46.google.com ([209.85.216.46]:51178 "EHLO mail-qa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755618AbaIWRDr (ORCPT ); Tue, 23 Sep 2014 13:03:47 -0400 MIME-Version: 1.0 X-Originating-IP: [46.139.80.5] In-Reply-To: <20140923162622.GA28059@ubuntu-hedt> References: <1409672696-15847-1-git-send-email-seth.forshee@canonical.com> <20140923162622.GA28059@ubuntu-hedt> Date: Tue, 23 Sep 2014 19:03:47 +0200 Message-ID: Subject: Re: [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces From: Miklos Szeredi To: Miklos Szeredi , "Eric W. Biederman" , Alexander Viro , Serge Hallyn , fuse-devel , Kernel Mailing List , Linux-Fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 23, 2014 at 6:26 PM, Seth Forshee wrote: > On Tue, Sep 23, 2014 at 06:07:35PM +0200, Miklos Szeredi wrote: >> On Tue, Sep 2, 2014 at 5:44 PM, Seth Forshee wrote: >> > Here's an updated set of patches for allowing fuse mounts from pid and >> > user namespaces. I discussed some of the issues we debated with the last >> > patch set (and a few others) with Eric at LinuxCon, and the updates here >> > mainly reflect the outcome of those discussions. >> > >> > The stickiest issue in the v1 patches was the question of where to get >> > the user and pid namespaces from that are used for translating ids for >> > communication with userspace. Eric told me that for user namespaces at >> > least we need to grab a namespace at open or mount time and use only >> > that namespace to prevent certain types of attacks. >> >> I'm not convinced. Let us have the gory details, please. > > I'll do my best, and hopefully Eric will fill in any details I miss. > > I think there may have been more than one possible scenario that Eric > was describing to me, but this is the one I remember. A user could > create a namespace and mount a fuse filesystem without nosuid. It could > then pass the /dev/fuse fd to a process in init_user_ns, which could > expose a suid file owned by root (or any other user) and use it to gain > elevated privileges. > > On the other hand, if file ownership is always interpreted in the > context of the namespace from which the filesystem is mounted then suid > can only be used to become another uid already under that user's > control. Much simpler solution: don't allow SUID in unprivileged namespaces. SUID is a really ugly hack with many problems, just get rid of it. Thanks, Miklos