Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752899AbbG3Nzz (ORCPT ); Thu, 30 Jul 2015 09:55:55 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:34200 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751467AbbG3Nzw (ORCPT ); Thu, 30 Jul 2015 09:55:52 -0400 Date: Thu, 30 Jul 2015 08:55:31 -0500 From: Seth Forshee To: Amir Goldstein Cc: "Theodore Ts'o" , Casey Schaufler , Stephen Smalley , Andy Lutomirski , "Eric W. Biederman" , Alexander Viro , Linux FS Devel , LSM List , SELinux-NSA , Serge Hallyn , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Message-ID: <20150730135531.GA109168@ubuntu-hedt> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2733 Lines: 61 On Thu, Jul 30, 2015 at 07:24:11AM +0300, Amir Goldstein wrote: > On Tue, Jul 28, 2015 at 11:40 PM, Seth Forshee > wrote: > > > > On Wed, Jul 22, 2015 at 05:05:17PM -0700, Casey Schaufler wrote: > > > > This is what I currently think you want for user ns mounts: > > > > > > > > 1. smk_root and smk_default are assigned the label of the backing > > > > device. > > Seth, > > There were 2 main concerns discussed in this thread: > 1. trusting LSM labels outside the namespace > 2. trusting the content of the image file/loopdev > > While your approach addresses the first concern, I suspect it may be placing > an obstacle in a way for resolving the second concern. > > A viable security policy to mitigate the second concern could be: > - Allow only trusted programs (e.g. mkfs, fsck) to write to 'Loopback' images > - Allow mount only of 'Loopback' images > > This should allow the system as a whole to trust unprivileged mounts based on > the trust of the entities that had raw access the the fs layout. You don't really say what you mean by "trusted" programs. In a container context I'd have to assume that you mean suid-root or similar programs shared into the container by the host. In that case is any new kernel functionality even required? That also doesn't work for some of our use cases, where we'd like to be able to do something like "mount -o loop foo.img /mnt/foo" in an unprivileged container where foo.img is not created on the local machine and not fully under control of the host environment. Agreed though that the "attack from below" problem for untrusted filesystems is still an open question. At minimum we have fuse, which has been designed to protect against this threat. Others have mentioned on this thread that Ted had said something at kernel summit last year about being willing to support ext4 mounts from unprivileged user namespaces as well. I've added Ted to the Cc in case he wants to confirm or deny this rumor. > Alas, if you choose to propagate the backing dev label to contained files, > they would all share the designated 'Loopback' label and render the policy above > useless. > > Any thoughts on how to reconcile this conflict? I'm not seeing what the conflict is here - nothing you proposed says anything about security labels in the filesystem, and nothing would prevent a "trusted" program with CAP_MAC_ADMIN from setting whatever label was desired on the backing device. Care to elaborate? Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/