From: Seth Forshee <seth.forshee@canonical.com> To: Amir Goldstein <amir@cellrox.com> Cc: "Theodore Ts'o" <tytso@mit.edu>, Casey Schaufler <casey@schaufler-ca.com>, Stephen Smalley <sds@tycho.nsa.gov>, Andy Lutomirski <luto@amacapital.net>, "Eric W. Biederman" <ebiederm@xmission.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, SELinux-NSA <selinux@tycho.nsa.gov>, Serge Hallyn <serge.hallyn@canonical.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Date: Thu, 30 Jul 2015 08:55:31 -0500 [thread overview] Message-ID: <20150730135531.GA109168@ubuntu-hedt> (raw) In-Reply-To: <CAOQ4uxi4vzf2ok23_ymUoyCjXMHBGY=GpypnTKE-zo-ZNB2SCw@mail.gmail.com> On Thu, Jul 30, 2015 at 07:24:11AM +0300, Amir Goldstein wrote: > On Tue, Jul 28, 2015 at 11:40 PM, Seth Forshee > <seth.forshee@canonical.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Seth Forshee <seth.forshee@canonical.com> To: Amir Goldstein <amir@cellrox.com> Cc: Serge Hallyn <serge.hallyn@canonical.com>, Theodore Ts'o <tytso@mit.edu>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, SELinux-NSA <selinux@tycho.nsa.gov>, Stephen Smalley <sds@tycho.nsa.gov>, Alexander Viro <viro@zeniv.linux.org.uk> Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts Date: Thu, 30 Jul 2015 08:55:31 -0500 [thread overview] Message-ID: <20150730135531.GA109168@ubuntu-hedt> (raw) In-Reply-To: <CAOQ4uxi4vzf2ok23_ymUoyCjXMHBGY=GpypnTKE-zo-ZNB2SCw@mail.gmail.com> On Thu, Jul 30, 2015 at 07:24:11AM +0300, Amir Goldstein wrote: > On Tue, Jul 28, 2015 at 11:40 PM, Seth Forshee > <seth.forshee@canonical.com> 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
next prev parent reply other threads:[~2015-07-30 13:55 UTC|newest] Thread overview: 138+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-07-30 4:24 [PATCH 0/7] Initial support for user namespace owned mounts Amir Goldstein 2015-07-30 4:24 ` Amir Goldstein 2015-07-30 13:55 ` Seth Forshee [this message] 2015-07-30 13:55 ` Seth Forshee 2015-07-30 14:47 ` Amir Goldstein 2015-07-30 14:47 ` Amir Goldstein 2015-07-30 15:33 ` Casey Schaufler 2015-07-30 15:33 ` Casey Schaufler 2015-07-30 15:52 ` Colin Walters 2015-07-30 15:52 ` Colin Walters 2015-07-30 16:15 ` Eric W. Biederman 2015-07-30 16:15 ` Eric W. Biederman 2015-07-30 13:57 ` Serge Hallyn 2015-07-30 13:57 ` Serge Hallyn 2015-07-30 15:09 ` Amir Goldstein 2015-07-30 15:09 ` Amir Goldstein -- strict thread matches above, loose matches on Subject: below -- 2015-07-31 8:11 Amir Goldstein 2015-07-31 8:11 ` Amir Goldstein 2015-07-31 19:56 ` Casey Schaufler 2015-07-31 19:56 ` Casey Schaufler 2015-08-01 17:01 ` Amir Goldstein 2015-08-01 17:01 ` Amir Goldstein 2015-07-15 19:46 Seth Forshee 2015-07-15 19:46 ` Seth Forshee 2015-07-15 20:36 ` Casey Schaufler 2015-07-15 20:36 ` Casey Schaufler 2015-07-15 21:06 ` Eric W. Biederman 2015-07-15 21:06 ` Eric W. Biederman 2015-07-15 21:48 ` Seth Forshee 2015-07-15 21:48 ` Seth Forshee 2015-07-15 22:28 ` Eric W. Biederman 2015-07-15 22:28 ` Eric W. Biederman 2015-07-16 1:05 ` Andy Lutomirski 2015-07-16 1:05 ` Andy Lutomirski 2015-07-16 2:20 ` Eric W. Biederman 2015-07-16 2:20 ` Eric W. Biederman 2015-07-16 13:12 ` Stephen Smalley 2015-07-16 13:12 ` Stephen Smalley 2015-07-15 23:04 ` Casey Schaufler 2015-07-15 23:04 ` Casey Schaufler 2015-07-15 22:39 ` Casey Schaufler 2015-07-15 22:39 ` Casey Schaufler 2015-07-16 1:08 ` Andy Lutomirski 2015-07-16 1:08 ` Andy Lutomirski 2015-07-16 2:54 ` Casey Schaufler 2015-07-16 2:54 ` Casey Schaufler 2015-07-16 4:47 ` Eric W. Biederman 2015-07-16 4:47 ` Eric W. Biederman 2015-07-17 0:09 ` Dave Chinner 2015-07-17 0:09 ` Dave Chinner 2015-07-17 0:42 ` Eric W. Biederman 2015-07-17 0:42 ` Eric W. Biederman 2015-07-17 2:47 ` Dave Chinner 2015-07-17 2:47 ` Dave Chinner 2015-07-21 17:37 ` J. Bruce Fields 2015-07-21 17:37 ` J. Bruce Fields 2015-07-22 7:56 ` Dave Chinner 2015-07-22 7:56 ` Dave Chinner 2015-07-22 14:09 ` J. Bruce Fields 2015-07-22 14:09 ` J. Bruce Fields 2015-07-22 16:52 ` Austin S Hemmelgarn 2015-07-22 16:52 ` Austin S Hemmelgarn 2015-07-22 17:41 ` J. Bruce Fields 2015-07-22 17:41 ` J. Bruce Fields 2015-07-23 1:51 ` Dave Chinner 2015-07-23 1:51 ` Dave Chinner 2015-07-23 13:19 ` J. Bruce Fields 2015-07-23 13:19 ` J. Bruce Fields 2015-07-23 23:48 ` Dave Chinner 2015-07-23 23:48 ` Dave Chinner 2015-07-18 0:07 ` Serge E. Hallyn 2015-07-18 0:07 ` Serge E. Hallyn 2015-07-20 17:54 ` Colin Walters 2015-07-20 17:54 ` Colin Walters 2015-07-16 11:16 ` Lukasz Pawelczyk 2015-07-16 11:16 ` Lukasz Pawelczyk 2015-07-17 0:10 ` Eric W. Biederman 2015-07-17 0:10 ` Eric W. Biederman 2015-07-17 10:13 ` Lukasz Pawelczyk 2015-07-17 10:13 ` Lukasz Pawelczyk 2015-07-16 3:15 ` Eric W. Biederman 2015-07-16 3:15 ` Eric W. Biederman 2015-07-16 13:59 ` Seth Forshee 2015-07-16 13:59 ` Seth Forshee 2015-07-16 15:09 ` Casey Schaufler 2015-07-16 15:09 ` Casey Schaufler 2015-07-16 18:57 ` Seth Forshee 2015-07-16 18:57 ` Seth Forshee 2015-07-16 21:42 ` Casey Schaufler 2015-07-16 21:42 ` Casey Schaufler 2015-07-16 22:27 ` Andy Lutomirski 2015-07-16 22:27 ` Andy Lutomirski 2015-07-16 23:08 ` Casey Schaufler 2015-07-16 23:08 ` Casey Schaufler 2015-07-16 23:29 ` Andy Lutomirski 2015-07-16 23:29 ` Andy Lutomirski 2015-07-17 0:45 ` Casey Schaufler 2015-07-17 0:45 ` Casey Schaufler 2015-07-17 0:59 ` Andy Lutomirski 2015-07-17 0:59 ` Andy Lutomirski 2015-07-17 14:28 ` Serge E. Hallyn 2015-07-17 14:28 ` Serge E. Hallyn 2015-07-17 14:56 ` Seth Forshee 2015-07-17 14:56 ` Seth Forshee 2015-07-21 20:35 ` Seth Forshee 2015-07-21 20:35 ` Seth Forshee 2015-07-22 1:52 ` Casey Schaufler 2015-07-22 1:52 ` Casey Schaufler 2015-07-22 15:56 ` Seth Forshee 2015-07-22 15:56 ` Seth Forshee 2015-07-22 18:10 ` Casey Schaufler 2015-07-22 18:10 ` Casey Schaufler 2015-07-22 19:32 ` Seth Forshee 2015-07-22 19:32 ` Seth Forshee 2015-07-23 0:05 ` Casey Schaufler 2015-07-23 0:05 ` Casey Schaufler 2015-07-23 0:15 ` Eric W. Biederman 2015-07-23 0:15 ` Eric W. Biederman 2015-07-23 5:15 ` Seth Forshee 2015-07-23 5:15 ` Seth Forshee 2015-07-23 21:48 ` Casey Schaufler 2015-07-23 21:48 ` Casey Schaufler 2015-07-28 20:40 ` Seth Forshee 2015-07-28 20:40 ` Seth Forshee 2015-07-30 16:18 ` Casey Schaufler 2015-07-30 16:18 ` Casey Schaufler 2015-07-30 17:05 ` Eric W. Biederman 2015-07-30 17:05 ` Eric W. Biederman 2015-07-30 17:25 ` Seth Forshee 2015-07-30 17:25 ` Seth Forshee 2015-07-30 17:33 ` Eric W. Biederman 2015-07-30 17:33 ` Eric W. Biederman 2015-07-17 13:21 ` Seth Forshee 2015-07-17 13:21 ` Seth Forshee 2015-07-17 17:14 ` Casey Schaufler 2015-07-17 17:14 ` Casey Schaufler 2015-07-16 15:59 ` Seth Forshee 2015-07-16 15:59 ` Seth Forshee
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150730135531.GA109168@ubuntu-hedt \ --to=seth.forshee@canonical.com \ --cc=amir@cellrox.com \ --cc=casey@schaufler-ca.com \ --cc=ebiederm@xmission.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ --cc=serge.hallyn@canonical.com \ --cc=tytso@mit.edu \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.