On Thu, Sep 05, 2013 at 02:22:11PM -0700, Eric W. Biederman wrote: > Vivek Goyal <vgoyal@xxxxxxxxxx> writes: > > > On Thu, Sep 05, 2013 at 01:39:26PM -0400, Vivek Goyal wrote: > >> On Thu, Sep 05, 2013 at 10:47:15AM -0400, Vivek Goyal wrote: > >> > On Thu, Sep 05, 2013 at 02:40:39PM +0000, Matthew Garrett wrote: > >> > > On Wed, 2013-09-04 at 20:49 -0400, Vivek Goyal wrote: > >> > > > >> > > > I did what Eric Biederman suggested. I first unshare the mount namespace > >> > > > of /sbin/kexec from parent. Then I disable any event propogation between > >> > > > mounts. Then I lazy unmount existing /proc and /sys and remount them. I > >> > > > think this should make sure that we are seeing at /proc and /sys as > >> > > > exported by kenrel? > >> > > > >> > > Namespaces have mostly been used with the assumption that namespaces > >> > > contain child processes, rather than parent processes attacking > >> > > children. Are we guaranteed that (barring ptrace) a parent process is > >> > > unable to manipulate a child's namespaces? > >> > > >> > This is a good question and I don't know enough about namespaces to > >> > be able to answer it. > >> > > >> > I am CCing Eric Biederman and he should have an Idea. > >> > > >> > Eric, > >> > > >> > So this is in context of kdump an secureboot. We were discussing to be > >> > able to create a private mount namespace for /sbin/kexec and remount > >> > /proc/ and /sys so that /sbin/kexec is sure that it is looking at > >> > something as exported by kernel. > >> > > >> > Is it possible for unsigned parent to now maninpulate child /sbin/kexec > >> > mount namespace now? > >> > >> I am not an expert in this area. I am reading following two articles. > >> > >> http://man7.org/linux/man-pages/man2/mount.2.html > >> http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html > >> > >> I think once we did unshare() child got its own mount name space and > >> after that we converted it into a private mount point. I think that > >> will ensure that no mount events are propagated from parent to child > >> and vice-a-versa. I doubt that now there is any way a parent can > >> modify child's mount namespace. > > > > I asked this question to Al Viro. And he thinks it should be fine. He > > mentioned though that make sure /proc and /sys are not symlinks. Otherwise > > after I have remounted /proc, root could remove /proc symlink and replace > > with directory of his choice and fake proc files in that dir. > > > > He did mention that a new mount option to *not follow symlink* might > > make sense. Initially I thought I can do stat(/proc) and if it is not > > symlink then mount /proc. But I think it is racy as root could replace > > /proc in between the symlink check and mount operation. > > > > I will see if I can write a patch to introduce new mount option. > > I would discourage that but with less privileged users being able to > mount filesystem that seems generally applicable. > > An important detail to look at is mount propagation, especially on > fedora. You need to make all of your mounts private to make certain > mounts don't propogate out and possibly take some defensive measures > to keep mounts or umounts from propogating in. Remount /proc > and /sys should be enough to defend against that but it is worth > thinking about. Hi Eric, I do make /sbin/kexec's mount namespace private recursively so that no mount events are propagated in/out. + * make root private so that no mount event from previous namespace + * are propogated + */ + ret = mount("", "/", "", MS_REC | MS_PRIVATE, ""); + if (ret == -1) { + fprintf(stderr, "mount(MS_REC|MS_PRIVATE) failed:%s\n", + strerror(errno)); + return -1; + } Thanks Vivek _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
