From: "Serge E. Hallyn" <serge@hallyn.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Al Viro <viro@ZenIV.linux.org.uk>,
Serge Hallyn <serge.hallyn@ubuntu.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] allow some kernel filesystems to be mounted in a user namespace
Date: Tue, 16 Jul 2013 21:37:48 +0000 [thread overview]
Message-ID: <20130716213748.GA24076@mail.hallyn.com> (raw)
In-Reply-To: <51E5BC0D.3090303@mit.edu>
Quoting Andy Lutomirski (luto@amacapital.net):
> On 07/16/2013 12:50 PM, Serge E. Hallyn wrote:
> > Quoting Al Viro (viro@ZenIV.linux.org.uk):
> >> On Tue, Jul 16, 2013 at 02:29:20PM -0500, Serge Hallyn wrote:
> >>> All the files will be owned by host root, so there's no security
> >>> concern in allowing this.
> >>
> >> Files owned by root != very bad things can't be done by non-root.
> >> Especially for debugfs, which is very much a "don't even think about
> >> mounting that on a production box" thing...
> >
> > I would prefer it not be mounted. But near as I can tell there
> > should be no regression security-wise whether an unprivileged
> > user on the host has access to it, or whether a user in a
> > non-init user ns is allowed to mount it. (Obviously I could very
> > well be wrong)
>
> I would argue that either (a) debugfs denies everything to non-root, so
> mounting it in a (rootless) userns is useless or (b) it doesn't, in
> which case it's dangerous.
>
> In neither case does it make sense to me to allow the mount.
It makes sense from the POV of having sane user-space. I can obviously
work around this by tweaking a stock container rootfs to be different
from a stock host rootfs. It is undesirable.
For debug and fusectl there is another option which I'm happy to
pursue, namely tweaking how mountall handles 'nofail' to ignore these
errors.
But for /sys/kernel/security, the failure of which to mount on a
non-container can be a real problem, that is not good enough. So
at least I'd like securityfs to be mountable in a non-init userns.
-serge
next prev parent reply other threads:[~2013-07-16 21:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 19:29 [PATCH RFC] allow some kernel filesystems to be mounted in a user namespace Serge Hallyn
2013-07-16 19:38 ` Al Viro
2013-07-16 19:50 ` Serge E. Hallyn
2013-07-16 21:33 ` Andy Lutomirski
2013-07-16 21:37 ` Serge E. Hallyn [this message]
2013-07-16 21:39 ` Serge E. Hallyn
2013-07-16 21:44 ` Andy Lutomirski
2013-07-16 22:03 ` Serge E. Hallyn
2013-07-16 22:07 ` Andy Lutomirski
2013-07-16 22:23 ` Serge E. Hallyn
2013-07-17 5:43 ` Eric W. Biederman
2013-07-17 12:41 ` Serge Hallyn
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=20130716213748.GA24076@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=serge.hallyn@ubuntu.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