[ 3.5.y.z extended stable ] Patch "ipc: Restrict mounting the mqueue filesystem" has been added to staging queue

[Luis Henriques]

On Wed, Apr 03, 2013 at 04:08:02PM -0700, Eric W. Biederman wrote:
> Luis Henriques <luis.henriques at canonical.com> writes:
> 
> > This is a note to let you know that I have just added a patch titled
> >
> >     ipc: Restrict mounting the mqueue filesystem
> >
> > to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
> > which can be found at:
> >
> >  http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue
> >
> > If you, or anyone else, feels it should not be added to this tree, please 
> > reply to this email.
> >
> > For more information about the 3.5.y.z tree, see
> > https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
> 
> Ugh.  I goofed in Cc'ing stable on this one.  I thought the relevant
> change was in 3.8 (below) but it turns out this didn't show up until 3.9-rc1.
> 
>      ommit bc1b69ed22a704fb1cc83d75b2eb46508a06c820
>      Author: Gao feng <gaofeng at cn.fujitsu.com>
>      Date:   Mon Jan 28 11:09:01 2013 +0800
>      
>          userns: Allow the unprivileged users to mount mqueue fs
> 
> So I believe this is a useless backport.
> 
> Not that it will do any harm...

Again, you're right.  Dropping this patch for 3.5.  Thanks a lot.

Cheers,
--
Luis

> 
> Eric
> 
> > From f3b5a4b904f65aa7b301d49e5a065da615467c16 Mon Sep 17 00:00:00 2001
> > From: "Eric W. Biederman" <ebiederm at xmission.com>
> > Date: Thu, 21 Mar 2013 18:13:15 -0700
> > Subject: [PATCH] ipc: Restrict mounting the mqueue filesystem
> >
> > commit a636b702ed1805e988ad3d8ff8b52c060f8b341c upstream.
> >
> > Only allow mounting the mqueue filesystem if the caller has CAP_SYS_ADMIN
> > rights over the ipc namespace.   The principle here is if you create
> > or have capabilities over it you can mount it, otherwise you get to live
> > with what other people have mounted.
> >
> > This information is not particularly sensitive and mqueue essentially
> > only reports which posix messages queues exist.  Still when creating a
> > restricted environment for an application to live any extra
> > information may be of use to someone with sufficient creativity.  The
> > historical if imperfect way this information has been restricted has
> > been not to allow mounts and restricting this to ipc namespace
> > creators maintains the spirit of the historical restriction.
> >
> > Acked-by: Serge Hallyn <serge.hallyn at canonical.com>
> > Signed-off-by: "Eric W. Biederman" <ebiederm at xmission.com>
> > Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
> > ---
> >  ipc/mqueue.c | 12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> > index 8ce5769..8513d4e 100644
> > --- a/ipc/mqueue.c
> > +++ b/ipc/mqueue.c
> > @@ -331,8 +331,16 @@ static struct dentry *mqueue_mount(struct file_system_type *fs_type,
> >  			 int flags, const char *dev_name,
> >  			 void *data)
> >  {
> > -	if (!(flags & MS_KERNMOUNT))
> > -		data = current->nsproxy->ipc_ns;
> > +	if (!(flags & MS_KERNMOUNT)) {
> > +		struct ipc_namespace *ns = current->nsproxy->ipc_ns;
> > +		/* Don't allow mounting unless the caller has CAP_SYS_ADMIN
> > +		 * over the ipc namespace.
> > +		 */
> > +		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
> > +			return ERR_PTR(-EPERM);
> > +
> > +		data = ns;
> > +	}
> >  	return mount_ns(fs_type, flags, data, mqueue_fill_super);
> >  }
> >
> > --
> > 1.8.1.2