linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Seth Forshee <seth.forshee@canonical.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: Fri, 17 Jul 2015 10:09:14 +1000	[thread overview]
Message-ID: <20150717000914.GO7943@dastard> (raw)
In-Reply-To: <87fv4owvxv.fsf@x220.int.ebiederm.org>

On Wed, Jul 15, 2015 at 11:47:08PM -0500, Eric W. Biederman wrote:
> Casey Schaufler <casey@schaufler-ca.com> writes:
> > On 7/15/2015 6:08 PM, Andy Lutomirski wrote:
> >> If I mount an unprivileged filesystem, then either the contents were
> >> put there *by me*, in which case letting me access them are fine, or
> >> (with Seth's patches and then some) I control the backing store, in
> >> which case I can do whatever I want regardless of what LSM thinks.
> >>
> >> So I don't see the problem.  Why would Smack or any other LSM care at
> >> all, unless it wants to prevent me from mounting the fs in the first
> >> place?
> >
> > First off, I don't cotton to the notion that you should be able
> > to mount filesystems without privilege. But it seems I'm being
> > outvoted on that. I suspect that there are cases where it might
> > be safe, but I can't think of one off the top of my head.
> 
> There are two fundamental issues mounting filesystems without privielge,
> by which I actually mean mounting filesystems as the root user in a user
> namespace.
> 
> - Are the semantics safe.
> - Is the extra attack surface a problem.

I think the attack surface this exposes is the biggest problem
facing this proposal.

> Figuring out how to make semantics safe is what we are talking about.
> 
> Once we sort out the semantics we can look at the handful of filesystems
> like fuse where the extra attack surface is not a concern.
> 
> With that said desktop environments have for a long time been
> automatically mounting whichever filesystem you place in your computer,
> so in practice what this is really about is trying to align the kernel
> with how people use filesystems.

The key difference is that desktops only do this when you physically
plug in a device. With unprivileged mounts, a hostile attacker
doesn't need physical access to the machine to exploit lurking
kernel filesystem bugs. i.e. they can just use loopback mounts, and
they can keep mounting corrupted images until they find something
that works.

User namespaces are supposed to provide trust separation.  The
kernel filesystems simply aren't hardened against unprivileged
attacks from below - there is a trust relationship between root and
the filesystem in that they are the only things that can write to
the disk. Mounts from within a userns destroys this relationship as
the userns root, by definition, is not a trusted actor.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2015-07-17  0:09 UTC|newest]

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15 19:46 [PATCH 0/7] Initial support for user namespace owned mounts Seth Forshee
2015-07-15 19:46 ` [PATCH 1/7] fs: Add user namesapace member to struct super_block Seth Forshee
2015-07-16  2:47   ` Eric W. Biederman
2015-08-05 21:03     ` Seth Forshee
2015-08-05 21:19       ` Eric W. Biederman
2015-08-06 14:20         ` Seth Forshee
2015-08-06 14:51           ` Stephen Smalley
2015-08-06 15:44             ` Seth Forshee
2015-08-06 16:11               ` Stephen Smalley
2015-08-07 14:16                 ` Seth Forshee
2015-08-07 14:32           ` Seth Forshee
2015-08-07 18:35             ` Casey Schaufler
2015-08-07 18:57               ` Seth Forshee
2015-07-15 19:46 ` [PATCH 2/7] userns: Simpilify MNT_NODEV handling Seth Forshee
2015-07-15 19:46 ` [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces Seth Forshee
2015-07-15 21:48   ` Serge E. Hallyn
2015-07-15 21:50     ` Andy Lutomirski
2015-07-15 22:35       ` Eric W. Biederman
2015-07-16  1:14         ` Seth Forshee
2015-07-16  1:23           ` Andy Lutomirski
2015-07-16 13:06             ` Seth Forshee
2015-07-16  1:19         ` Andy Lutomirski
2015-07-16  4:23           ` Eric W. Biederman
2015-07-16  4:49             ` Andy Lutomirski
2015-07-16  5:04               ` Eric W. Biederman
2015-07-16  5:15                 ` Andy Lutomirski
2015-07-16  5:44                   ` Eric W. Biederman
2015-07-16 13:13                     ` Seth Forshee
2015-07-17  0:43                       ` Eric W. Biederman
2015-07-29 16:04                 ` Serge E. Hallyn
2015-07-29 16:18                   ` Serge E. Hallyn
2015-07-15 19:46 ` [PATCH 4/7] fs: Treat foreign mounts as nosuid Seth Forshee
2015-07-17  6:46   ` Nikolay Borisov
2015-07-15 19:46 ` [PATCH 5/7] security: Restrict security attribute updates for userns mounts Seth Forshee
2015-07-15 19:46 ` [PATCH 6/7] selinux: Ignore security labels on user namespace mounts Seth Forshee
2015-07-16 13:23   ` Stephen Smalley
2015-07-22 16:02     ` Stephen Smalley
2015-07-22 16:14       ` Seth Forshee
2015-07-22 20:25         ` Stephen Smalley
2015-07-22 20:40           ` Stephen Smalley
2015-07-23 13:57             ` Stephen Smalley
2015-07-23 14:39               ` Seth Forshee
2015-07-23 15:36                 ` Stephen Smalley
2015-07-23 16:23                   ` Seth Forshee
2015-07-24 15:11                     ` Seth Forshee
2015-07-30 15:57                       ` Stephen Smalley
2015-07-30 16:24                         ` Seth Forshee
2015-07-15 19:46 ` [PATCH 7/7] smack: Don't use security labels for " Seth Forshee
2015-07-15 20:43   ` Casey Schaufler
2015-07-15 20:36 ` [PATCH 0/7] Initial support for user namespace owned mounts Casey Schaufler
2015-07-15 21:06   ` Eric W. Biederman
2015-07-15 21:48     ` Seth Forshee
2015-07-15 22:28       ` Eric W. Biederman
2015-07-16  1:05         ` Andy Lutomirski
2015-07-16  2:20           ` Eric W. Biederman
2015-07-16 13:12           ` Stephen Smalley
2015-07-15 23:04       ` Casey Schaufler
2015-07-15 22:39     ` Casey Schaufler
2015-07-16  1:08       ` Andy Lutomirski
2015-07-16  2:54         ` Casey Schaufler
2015-07-16  4:47           ` Eric W. Biederman
2015-07-17  0:09             ` Dave Chinner [this message]
2015-07-17  0:42               ` Eric W. Biederman
2015-07-17  2:47                 ` Dave Chinner
2015-07-21 17:37                   ` J. Bruce Fields
2015-07-22  7:56                     ` Dave Chinner
2015-07-22 14:09                       ` J. Bruce Fields
2015-07-22 16:52                         ` Austin S Hemmelgarn
2015-07-22 17:41                           ` J. Bruce Fields
2015-07-23  1:51                             ` Dave Chinner
2015-07-23 13:19                               ` J. Bruce Fields
2015-07-23 23:48                                 ` Dave Chinner
2015-07-18  0:07                 ` Serge E. Hallyn
2015-07-20 17:54             ` Colin Walters
2015-07-16 11:16     ` Lukasz Pawelczyk
2015-07-17  0:10       ` Eric W. Biederman
2015-07-17 10:13         ` Lukasz Pawelczyk
2015-07-16  3:15 ` Eric W. Biederman
2015-07-16 13:59   ` Seth Forshee
2015-07-16 15:09     ` Casey Schaufler
2015-07-16 18:57       ` Seth Forshee
2015-07-16 21:42         ` Casey Schaufler
2015-07-16 22:27           ` Andy Lutomirski
2015-07-16 23:08             ` Casey Schaufler
2015-07-16 23:29               ` Andy Lutomirski
2015-07-17  0:45                 ` Casey Schaufler
2015-07-17  0:59                   ` Andy Lutomirski
2015-07-17 14:28                     ` Serge E. Hallyn
2015-07-17 14:56                       ` Seth Forshee
2015-07-21 20:35                     ` Seth Forshee
2015-07-22  1:52                       ` Casey Schaufler
2015-07-22 15:56                         ` Seth Forshee
2015-07-22 18:10                           ` Casey Schaufler
2015-07-22 19:32                             ` Seth Forshee
2015-07-23  0:05                               ` Casey Schaufler
2015-07-23  0:15                                 ` Eric W. Biederman
2015-07-23  5:15                                   ` Seth Forshee
2015-07-23 21:48                                   ` Casey Schaufler
2015-07-28 20:40                                 ` Seth Forshee
2015-07-30 16:18                                   ` Casey Schaufler
2015-07-30 17:05                                     ` Eric W. Biederman
2015-07-30 17:25                                       ` Seth Forshee
2015-07-30 17:33                                         ` Eric W. Biederman
2015-07-17 13:21           ` Seth Forshee
2015-07-17 17:14             ` Casey Schaufler
2015-07-16 15:59     ` Seth Forshee
  -- strict thread matches above, loose matches on Subject: below --
2015-07-30  4:24 Amir Goldstein
2015-07-30 13:55 ` Seth Forshee
2015-07-30 14:47   ` Amir Goldstein
2015-07-30 15:33     ` Casey Schaufler
2015-07-30 15:52       ` Colin Walters
2015-07-30 16:15         ` Eric W. Biederman
2015-07-30 13:57 ` Serge Hallyn
2015-07-30 15:09   ` Amir Goldstein
2015-07-31  8:11 Amir Goldstein
2015-07-31 19:56 ` Casey Schaufler
2015-08-01 17:01   ` Amir Goldstein

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=20150717000914.GO7943@dastard \
    --to=david@fromorbit.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=selinux@tycho.nsa.gov \
    --cc=serge.hallyn@canonical.com \
    --cc=seth.forshee@canonical.com \
    --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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).