From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Cc: Linux FS Devel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
Subject: Re: [REVIEW][PATCH 1/2] userns: Better restrictions on when proc and sysfs can be mounted
Date: Fri, 15 Nov 2013 00:37:13 -0800 [thread overview]
Message-ID: <87d2m2t612.fsf@xmission.com> (raw)
In-Reply-To: <5285BBE2.7010001-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> (Gao feng's message of "Fri, 15 Nov 2013 14:14:58 +0800")
Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:
> Ok,I agree with you that we should make container security by default.
>
> What's your idea that introduces option MS_NOT_A_LOCK just like Andy's
> advisement?
It might be doable but it is unnecessary.
> In libvirt, host creates dev and devpts directories for container,then
> mount devpts, tmpfs on them and create device nodes inside these dirs
> for container. and then in container, these filesystems are moved to
> container's /dev/ /dev/pts directory. We really have no need to lock
> these mounts. they are just created for container.
If the global root creates the namespace and performs all of the mounts
it is unnecessary.
Now I believe you can create those directories for the most part as
non-root in libvirt and gain some interesting applications.
That said if you don't want locked mounts you just just be able to
create a temporary mount namespace as the global root, and do your prep
work.
Then create your unprivileged mount namespace and bind mount the
directories where you want them, and then pivot_root away the bits you
don't want.
There is already more mechanism than I like to deal with the mount
namespace I would really rather not invent/debug/support any more.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Gao feng <gaofeng@cn.fujitsu.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Linux Containers <containers@lists.linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [REVIEW][PATCH 1/2] userns: Better restrictions on when proc and sysfs can be mounted
Date: Fri, 15 Nov 2013 00:37:13 -0800 [thread overview]
Message-ID: <87d2m2t612.fsf@xmission.com> (raw)
In-Reply-To: <5285BBE2.7010001@cn.fujitsu.com> (Gao feng's message of "Fri, 15 Nov 2013 14:14:58 +0800")
Gao feng <gaofeng@cn.fujitsu.com> writes:
> Ok,I agree with you that we should make container security by default.
>
> What's your idea that introduces option MS_NOT_A_LOCK just like Andy's
> advisement?
It might be doable but it is unnecessary.
> In libvirt, host creates dev and devpts directories for container,then
> mount devpts, tmpfs on them and create device nodes inside these dirs
> for container. and then in container, these filesystems are moved to
> container's /dev/ /dev/pts directory. We really have no need to lock
> these mounts. they are just created for container.
If the global root creates the namespace and performs all of the mounts
it is unnecessary.
Now I believe you can create those directories for the most part as
non-root in libvirt and gain some interesting applications.
That said if you don't want locked mounts you just just be able to
create a temporary mount namespace as the global root, and do your prep
work.
Then create your unprivileged mount namespace and bind mount the
directories where you want them, and then pivot_root away the bits you
don't want.
There is already more mechanism than I like to deal with the mount
namespace I would really rather not invent/debug/support any more.
Eric
next prev parent reply other threads:[~2013-11-15 8:37 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 21:44 [REVIEW][PATCH 1/2] userns: Better restrictions on when proc and sysfs can be mounted Eric W. Biederman
2013-08-27 21:44 ` Eric W. Biederman
[not found] ` <878uzmhkqg.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-08-27 21:46 ` [REVIEW][PATCH 2/2] sysfs: Restrict mounting sysfs Eric W. Biederman
2013-08-27 21:46 ` Eric W. Biederman
[not found] ` <874naahkng.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-08-28 19:00 ` Greg Kroah-Hartman
2013-08-28 19:00 ` Greg Kroah-Hartman
2013-09-23 10:33 ` James Hogan
2013-09-23 10:33 ` James Hogan
[not found] ` <524018EA.9070202-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2013-09-23 21:41 ` [PATCH] sysfs: Allow mounting without CONFIG_NET Eric W. Biederman
2013-09-23 21:41 ` Eric W. Biederman
[not found] ` <87ioxrrzb6.fsf_-_-HxuHnoDHeQZYhcs0q7wBk77fW72O3V7zAL8bYrjMMd8@public.gmane.org>
2013-09-24 11:25 ` James Hogan
2013-09-24 11:25 ` James Hogan
2013-08-27 21:47 ` [REVIEW][PATCH 1/2] userns: Better restrictions on when proc and sysfs can be mounted Andy Lutomirski
2013-08-27 21:47 ` Andy Lutomirski
[not found] ` <CALCETrWPDzuoaJp2ko5jAbwYUBqSdPjvO5uGo-gZVsS4Wm1PKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-27 21:57 ` Eric W. Biederman
2013-08-27 21:57 ` Eric W. Biederman
2013-09-01 4:45 ` Eric W. Biederman
[not found] ` <87eh99noa0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-09-03 17:40 ` Andy Lutomirski
2013-09-03 17:40 ` Andy Lutomirski
[not found] ` <87a9k2g5la.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-09-01 4:45 ` Eric W. Biederman
2013-11-02 6:06 ` Gao feng
2013-11-02 6:06 ` Gao feng
[not found] ` <52749663.2000701-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-04 7:00 ` Janne Karhunen
2013-11-04 7:00 ` Janne Karhunen
[not found] ` <CAE=NcrY+CzX+H4XQTdGj7CSZ98a5T=bNgT6=jGZzcjyaHb-ttw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-09 5:22 ` Eric W. Biederman
2013-11-09 5:22 ` Eric W. Biederman
2013-11-08 2:33 ` Gao feng
2013-11-08 2:33 ` Gao feng
[not found] ` <527C4D88.10907-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-09 5:42 ` Eric W. Biederman
2013-11-09 5:42 ` Eric W. Biederman
[not found] ` <87k3gigmgj.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-13 7:26 ` Gao feng
2013-11-13 7:26 ` Gao feng
[not found] ` <5283299B.8080702-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-14 11:10 ` Gao feng
2013-11-14 11:10 ` Gao feng
2013-11-14 11:10 ` Gao feng
[not found] ` <5284AF90.7060506-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-14 16:54 ` Andy Lutomirski
2013-11-14 16:54 ` Andy Lutomirski
[not found] ` <CALCETrXtWtF=JgiwENNzh7UZKnXijHauOQ5ZjHYxYJC-BAU5Aw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-15 1:16 ` Gao feng
2013-11-15 1:16 ` Gao feng
[not found] ` <528575EC.2030309-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-15 4:54 ` Eric W. Biederman
2013-11-15 4:54 ` Eric W. Biederman
[not found] ` <87txfexo25.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-11-15 6:14 ` Gao feng
2013-11-15 6:14 ` Gao feng
[not found] ` <5285BBE2.7010001-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-15 8:37 ` Eric W. Biederman [this message]
2013-11-15 8:37 ` Eric W. Biederman
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=87d2m2t612.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
/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.