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. Eric _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
