From: Seth Forshee <seth.forshee@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"Serge H. Hallyn" <serge.hallyn@ubuntu.com>,
Andy Lutomirski <luto@amacapital.net>,
Michael j Theall <mtheall@us.ibm.com>,
fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, seth.forshee@canonical.com
Subject: Re: [PATCH v5 3/4] fuse: Restrict allow_other to the superblock's namespace or a descendant
Date: Tue, 11 Nov 2014 09:37:32 -0600 [thread overview]
Message-ID: <20141111153732.GC7906@ubuntu-hedt> (raw)
In-Reply-To: <20141111152737.GE333@tucsk>
On Tue, Nov 11, 2014 at 04:27:37PM +0100, Miklos Szeredi wrote:
> On Wed, Oct 22, 2014 at 04:24:19PM -0500, Seth Forshee wrote:
> > Unprivileged users are normally restricted from mounting with the
> > allow_other option by system policy, but this could be bypassed
> > for a mount done with user namespace root permissions. In such
> > cases allow_oth er should not allow users outside the userns
> > to access the mount as doing so would give the unprivileged user
> > the ability to manipulate processes it would otherwise be unable
> > to manipulate. Therefore access with allow_other should be
> > restricted to users in the userns as the superblock or a
> > descendant of that namespace.
>
> Fine.
>
> But aren't this kind of thing supposed to be prevented anyway by having private
> mount namespace coupled with the pid-user-whatever namespace?
>
> It seems like being a bit too careful (not to say that that's a bad thing).
A userns mount should be in a "private" mount namespace; specifically
the user performing the mount must have CAP_SYS_ADMIN in
mnt_ns->user_ns. The mount may still be accessible via /proc/pid/root
though, and doing this ensures that in any case the user can never use
the mount to manipulate processes that it can't already manipulate.
Thanks,
Seth
next prev parent reply other threads:[~2014-11-11 15:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 21:24 [PATCH v5 0/4] fuse: Add support for mounts from pid/user namespaces Seth Forshee
2014-10-22 21:24 ` [PATCH v5 1/4] fuse: Add support for pid namespaces Seth Forshee
2014-11-11 13:27 ` Miklos Szeredi
2014-11-11 15:24 ` Seth Forshee
2014-11-11 15:39 ` Andy Lutomirski
2014-11-11 16:26 ` Seth Forshee
2014-11-12 12:07 ` Miklos Szeredi
2014-11-12 14:33 ` Seth Forshee
2014-10-22 21:24 ` [PATCH v5 2/4] fuse: Support fuse filesystems outside of init_user_ns Seth Forshee
2014-10-22 21:47 ` Andy Lutomirski
2014-11-11 14:04 ` Miklos Szeredi
2014-11-11 15:27 ` Seth Forshee
2014-11-11 15:37 ` Eric W. Biederman
2014-11-12 13:09 ` Miklos Szeredi
2014-11-12 16:22 ` Seth Forshee
2014-11-18 15:21 ` Seth Forshee
2014-11-18 17:09 ` Andy Lutomirski
2014-11-18 17:13 ` Seth Forshee
2014-11-18 17:19 ` Andy Lutomirski
2014-11-19 8:50 ` Miklos Szeredi
2014-11-19 10:38 ` Miklos Szeredi
2014-11-19 14:09 ` Serge E. Hallyn
2014-11-21 16:44 ` Seth Forshee
2014-11-21 17:19 ` Andy Lutomirski
2014-11-21 18:14 ` Eric W. Biederman
2014-11-21 18:25 ` Andy Lutomirski
2014-11-21 18:27 ` Seth Forshee
2014-11-21 18:38 ` Andy Lutomirski
2014-10-22 21:24 ` [PATCH v5 3/4] fuse: Restrict allow_other to the superblock's namespace or a descendant Seth Forshee
2014-10-22 21:48 ` Andy Lutomirski
2014-11-11 15:27 ` Miklos Szeredi
2014-11-11 15:37 ` Seth Forshee [this message]
2014-10-22 21:24 ` [PATCH v5 4/4] fuse: Allow user namespace mounts Seth Forshee
2014-10-22 21:51 ` Andy Lutomirski
2014-10-23 0:22 ` Seth Forshee
2014-10-23 2:19 ` Andy Lutomirski
2014-11-03 17:15 ` [PATCH v5 0/4] fuse: Add support for mounts from pid/user namespaces Seth Forshee
2014-11-03 17:17 ` Andy Lutomirski
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=20141111153732.GC7906@ubuntu-hedt \
--to=seth.forshee@canonical.com \
--cc=ebiederm@xmission.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=miklos@szeredi.hu \
--cc=mtheall@us.ibm.com \
--cc=serge.hallyn@ubuntu.com \
/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).