Re: [Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Vivek Goyal]

On Wed, Sep 04, 2013 at 09:51:27PM +0000, Matthew Garrett wrote:
>  On Wed, 2013-09-04 at 17:24 -0400, Vivek Goyal wrote:
>  > User space kexec-tools need to know whether to verify signature of kernel
>  > image being loaded. This patch exports two knobs to user space. One is
>  > for knowing if  secureboot is enabled, this knob will be set to 1 if secure
>  > boot is enabled. Other knob is secure_module_enabled. This knob will be set
>  > to 1 if secure modules is one.
>  
>  How are you verifying that you're really looking at sysfs? 
[ CCing kexec fedora list ]

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?

I will soon post my kexec-tools patches too on this list to show exactly
what I am doing. In short this is what I am doing.

- ret = unshare(CLONE_NEWNS);
- ret = mount("", "/", "", MS_REC | MS_PRIVATE,
"");
- ret = umount2("/proc", MNT_DETACH);
- ret = mount("none", "/proc", "proc", 0, "");
- ret = umount2("/sys", MNT_DETACH);
- ret = mount("none", "/sys", "sysfs", 0, "");

Thanks
Vivek

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Matthew Garrett]

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?

-- 
Matthew Garrett <matthew.garrett(a)nebula.com&gt;

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Vivek Goyal]

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? 

Thanks
Vivek

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Vivek Goyal]

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....

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. 

Thanks
Vivek

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Vivek Goyal]

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....
>  
>  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.

Thanks
Vivek

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Eric W. Biederman]

Vivek Goyal <vgoyal(a)redhat.com&gt; 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....
> > 
> > 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

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Vivek Goyal]

On Thu, Sep 05, 2013 at 02:22:11PM -0700, Eric W. Biederman wrote:
>  Vivek Goyal <vgoyal(a)redhat.com&gt; 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....
>  >> 
>  >> 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

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Eric W. Biederman]

Vivek Goyal <vgoyal(a)redhat.com&gt; writes:

>  On Thu, Sep 05, 2013 at 02:22:11PM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal(a)redhat.com&gt; 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....
> > >> 
> > >> 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;
>  +	} 
That prevents transmission but my previous read of the code says you
will still receive mount changes, for mount points the parent shares.
Which are all of them in the world of systemd, last I heard.

Eric

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Vivek Goyal]

On Thu, Sep 05, 2013 at 02:47:25PM -0700, Eric W. Biederman wrote:

[..]
>  >> 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;
>  > +	}
>  
>  That prevents transmission but my previous read of the code says you
>  will still receive mount changes, for mount points the parent shares.
>  Which are all of them in the world of systemd, last I heard. 
Hi Eric,

I think I am not understanding something very basic. I am not sure what do
you mean by "still receive mount changes for mount points the parent shares".
I tried following.

- Open a terminal
- mkdir /tmp/kexec-proc
- mount -t proc none /tmp/kexec-proc
- Now open another terminal and launch a bash shell with separate mount
  namespace
  unshare -m bash
- In the new bash shell  I can see that proc is mounted on /tmp/kexec-proc
- In the new bash shell, make / private recursively.
  mount --make-rprivate /
- Now in original bash shell unmount /tmp/kexec-proc
- I go back to new bash and there /tmp/kexec-proc is still mounted. So
  changes to original mount namespace did not reflect in this new one. I
  am assuming same will happen when systemd does some changes to initial
  mount namespace and they should not be visible in /sbin/kexec mount
  namespace.

Looks like I am entirely missing the point you are making. Can you please
elaborate a bit.

Thanks
Vivek

[Fedora 15/19] kexec: Export sysfs attributes for secureboot and secure modules to user space

[Eric W. Biederman]

Vivek Goyal <vgoyal(a)redhat.com&gt; writes:

>  On Thu, Sep 05, 2013 at 02:47:25PM -0700, Eric W. Biederman wrote:
>
>  [..]
> > >> 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;
> > > +	}
> > 
> > That prevents transmission but my previous read of the code says you
> > will still receive mount changes, for mount points the parent shares.
> > Which are all of them in the world of systemd, last I heard.
>
>  Hi Eric,
>
>  I think I am not understanding something very basic. I am not sure what do
>  you mean by "still receive mount changes for mount points the parent shares".
>  I tried following.
>
>  - Open a terminal
>  - mkdir /tmp/kexec-proc
>  - mount -t proc none /tmp/kexec-proc
>  - Now open another terminal and launch a bash shell with separate mount
>    namespace
>    unshare -m bash
>  - In the new bash shell  I can see that proc is mounted on /tmp/kexec-proc
>  - In the new bash shell, make / private recursively.
>    mount --make-rprivate /
>  - Now in original bash shell unmount /tmp/kexec-proc
>  - I go back to new bash and there /tmp/kexec-proc is still mounted. So
>    changes to original mount namespace did not reflect in this new one. I
>    am assuming same will happen when systemd does some changes to initial
>    mount namespace and they should not be visible in /sbin/kexec mount
>    namespace.
>
>  Looks like I am entirely missing the point you are making. Can you please
>  elaborate a bit. 
My apologies.  It appears I had mount --make-rslave / and mount --make-rprivate
scrambled in my head.

Private does indeed prevent mounts from propogating in from the parent
mount namespade.

Eric