linux-kernel - Re: [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140925162127.GA28101@ubuntu-hedt>
Date:	Thu, 25 Sep 2014 11:21:27 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	fuse-devel <fuse-devel@...ts.sourceforge.net>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] fuse: Add support for mounts from pid/user
 namespaces

On Thu, Sep 25, 2014 at 05:04:04PM +0200, Miklos Szeredi wrote:
> On Wed, Sep 24, 2014 at 7:10 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
> 
> 
> > So in summary I see:
> > - Low utility in being able to manipulate files with bad uids.
> > - Bad uids are mostly likely malicious action.
> > - make_bad_inode is trivial to analyze.
> > - No impediments to change if I am wrong.
> >
> > So unless there is a compelling case, right now I would recommend
> > returning -EIO initially.   That allows us to concentrate on the easier
> > parts of this and it leaves the changes only in fuse.
> 
> The problem with marking the inode bad is that it will mark it bad for
> all instances of this filesystem.  Including ones which are in a
> namespace where the UIDs make perfect sense.

As far as I can tell there can only be one interpretation of the uid
userspace hands us for an inode per superblock. If userspace hands us
1000 it can't map to kuid 101000 in one context and 1000 in another
context because there's only one inode. If the uid doesn't map into
whatever namespace we're using to interpret it there's no value for
i_uid which will cause it to be re-evaluated in a different context.

I don't think it would be a good idea to do that anyway. /proc is
mounted in my unprivileged container (i.e. uid 0 in the container maps
to some unprivileged uid outside the container). Interpreting uid 0 in
/proc relative to my container's namespace would give root in the
container access to things that it shouldn't have access to.

Thanks,
Seth

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/