linux-kernel - Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in 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: <20140521223319.GF29211@ubuntumail>
Date:	Wed, 21 May 2014 22:33:19 +0000
From:	Serge Hallyn <serge.hallyn@...ntu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Seth Forshee <seth.forshee@...onical.com>,
	Jens Axboe <axboe@...nel.dk>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	LXC development mailing-list 
	<lxc-devel@...ts.linuxcontainers.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user
 namespaces

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> 
> 
> >> Ultimately the technical challenge is how do we create a block device
> >> that is safe for a user who does not have any capabilities to use, and
> >> what can we do with that block device to make it useful.
> >
> > Yes, and I'd like to get started solving those challenges. But I also
> > don't think we can address these two points (support partition blkdevs,
> > help prevent more priveleged users from using a namespace's loop
> > devices) sufficiently while having an implementation completely
> > contained within the loop driver as Greg is requesting.
> 
> My key take away from the conversation is that we should reduce the
> scope of what is being done to something that makes sense and the
> propblems are immediately visible.
> 
> Part of me would like to suggest that fuse and it's ability to imitate
> device nodes might be a more appropriate solution, to something that

Do you have a link to more info on this?  Some googling got me to an
interesting but old thread on CUSE, but nothing specifically about fuse
doing this.

> just needs block device access and nothing else.
> 
> For purposes of discussion let's call it unprivloopfs.  That can reuse
> code from the loop device or not as appropriate.  Not supporting
> paritioning I think is a very reasonable first step until it is shown
> that we can make good use of partitioning support, and there are not
> better ways of solving the problem.
> 
> I expect the most productive thing to talk about is what is your
> immediate goal?  Mounting a filesystem?  Building an iso?

For me it would be taking an iso and making some changes to it to
localize it (i.e. take an install iso and add preseed file).

Now of course in the end there is no reason why we can't do all of
this with a new suite of libraries which simply uses read/write with
knowledge of the fs layouts to parse and modify the backing files.
My concern there is that duplicating all of the fs code seems unlikely
to improve the soundness of either implementation.  Perhaps we can
autogenerate this from the kernel source?  Does fuse already do
something like that?

> We have a long history with the namespace support of punting on issues
> and not solving them until a long term maintainable solution becomes
> clear.  Let's do what we can to make the problem and the solution clear.

-serge
--
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/