All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-bcache@vger.kernel.org, dm-devel@redhat.com,
	linux-raid@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Andy Lutomirski <luto@amacapital.net>,
	linux-kernel@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH v3 0/7] User namespace mount updates
Date: Tue, 17 Nov 2015 21:05:42 +0000	[thread overview]
Message-ID: <20151117210542.GY22011@ZenIV.linux.org.uk> (raw)
In-Reply-To: <564B9074.5030305@gmail.com>

On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:

> >This is absolutely insane, no matter how much LSM snake oil you slatter on
> >the whole thing.  All of a sudden you are exposing a huge attack surface
> >in the place where it would hurt most and as the consolation we are offered
> >basically "Ted is willing to fix holes when they are found".
> For the context of static image attacks, anything that's found
> _needs_ to be fixed regardless, and unless you can find some way to
> actually prevent attacks on mounted filesystems that doesn't involve
> a complete re-write of the filesystem drivers, then there's not much
> we can do about it.  Yes, unprivileged mounts expose an attack
> surface, but so does userspace access to the network stack, and so
> do a lot of other features that are considered essential in a modern
> general purpose operating system.

"X is exposes an attack surface.  Y exposes a diferent attack surface.
Y is considered important.  Therefore X is important enough to implement it"

Right...

  reply	other threads:[~2015-11-17 21:05 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17 16:39 [PATCH v3 0/7] User namespace mount updates Seth Forshee
2015-11-17 16:39 ` [PATCH v3 1/7] block_dev: Support checking inode permissions in lookup_bdev() Seth Forshee
2015-11-17 16:39 ` [PATCH v3 2/7] block_dev: Check permissions towards block device inode when mounting Seth Forshee
2015-11-17 16:39 ` [PATCH v3 3/7] mtd: Check permissions towards mtd " Seth Forshee
2015-11-17 16:39 ` [PATCH v3 4/7] fs: Treat foreign mounts as nosuid Seth Forshee
2015-11-18  0:00   ` James Morris
2015-11-17 16:39 ` [PATCH v3 5/7] selinux: Add support for unprivileged mounts from user namespaces Seth Forshee
2015-11-18  0:02   ` James Morris
2015-11-17 16:39 ` [PATCH v3 6/7] userns: Replace in_userns with current_in_userns Seth Forshee
2015-11-18  0:03   ` James Morris
2015-11-17 16:39 ` [PATCH v3 7/7] Smack: Handle labels consistently in untrusted mounts Seth Forshee
2015-11-17 18:24   ` Casey Schaufler
2015-11-17 18:24     ` Casey Schaufler
2015-11-18  0:12   ` James Morris
2015-11-18  0:50     ` Seth Forshee
2015-11-17 17:05 ` [PATCH v3 0/7] User namespace mount updates Al Viro
2015-11-17 17:25   ` Seth Forshee
2015-11-17 17:45     ` Serge E. Hallyn
2015-11-17 17:55     ` Al Viro
2015-11-17 18:34       ` Seth Forshee
2015-11-17 19:12         ` Richard Weinberger
2015-11-17 19:21           ` Seth Forshee
2015-11-17 19:25             ` Octavian Purdila
2015-11-17 20:12               ` Richard Weinberger
2015-11-17 22:00                 ` Octavian Purdila
2015-11-19 15:23                   ` Seth Forshee
2015-11-19 16:19                     ` Octavian Purdila
2015-11-19 16:31                       ` Seth Forshee
2015-11-20 17:33                       ` Serge E. Hallyn
2015-11-17 19:26             ` Richard Weinberger
2015-11-18 19:10         ` Theodore Ts'o
2015-11-18 19:28           ` Seth Forshee
2015-11-18 19:32           ` Serge Hallyn
2015-11-17 19:02       ` Austin S Hemmelgarn
2015-11-17 19:16         ` Seth Forshee
2015-11-17 19:16           ` Seth Forshee
2015-11-17 20:54           ` Austin S Hemmelgarn
2015-11-17 21:32             ` Seth Forshee
2015-11-18 12:23               ` Austin S Hemmelgarn
2015-11-18 14:22                 ` Seth Forshee
2015-11-18 14:58                   ` Al Viro
2015-11-18 15:05                     ` Seth Forshee
2015-11-18 15:05                       ` Seth Forshee
2015-11-18 15:13                       ` Al Viro
2015-11-18 15:19                         ` Richard Weinberger
2015-11-19  7:47                           ` James Morris
2015-11-19  7:53                             ` Richard Weinberger
2015-11-19 14:21                               ` Serge E. Hallyn
2015-11-19 15:04                                 ` Richard Weinberger
2015-11-19 14:37                               ` Colin Walters
2015-11-19 14:49                                 ` Richard Weinberger
2015-11-19 15:17                                   ` Richard W.M. Jones
2015-11-19 14:58                         ` Serge E. Hallyn
2015-11-18 15:34                     ` Austin S Hemmelgarn
2015-11-18 15:36                     ` Nikolay Borisov
2015-11-17 19:30         ` Al Viro
2015-11-17 20:39           ` Austin S Hemmelgarn
2015-11-17 21:05             ` Al Viro [this message]
2015-11-17 22:01               ` Seth Forshee
2015-11-18 12:46                 ` Austin S Hemmelgarn
2015-11-18 14:30                   ` Seth Forshee
2015-11-18 15:38                     ` Austin S Hemmelgarn
     [not found]                       ` <564C9B92.5080107-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-11-18 18:33                         ` Daniel J Walsh
2015-11-18 18:33                           ` Daniel J Walsh
2015-11-18 18:33                           ` Daniel J Walsh
2015-11-18 18:44           ` J. Bruce Fields

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=20151117210542.GY22011@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=ahferroin7@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-raid@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=tytso@mit.edu \
    /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 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.