All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Igor Zhbanov <izh1979@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	neilb@suse.de, Trond.Myklebust@netapp.com,
	David Howells <dhowells@redhat.com>,
	Andrew Morgan <morgan@kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	SELinux <selinux@tycho.nsa.gov>
Subject: Re: Ответ: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK?
Date: Mon, 16 Mar 2009 18:03:42 -0500	[thread overview]
Message-ID: <20090316230342.GB15522@us.ibm.com> (raw)
In-Reply-To: <20090316224848.GC17738@fieldses.org>

Quoting J. Bruce Fields (bfields@fieldses.org):
> Seems this isn't entirely obvious in the general case.  In the specific

I think the MKNOD part is (based on historical behavior as you
suggested) obvious:  both masks should include CAP_MKNOD and
CAP_LINUX_IMMUTABLE.

(references: http://lxr.linux.no/linux-old+v2.0.21/fs/ext2/ioctl.c#L60
for immutable and http://lxr.linux.no/linux-old+v2.0.21/fs/namei.c#L503
for mknod)

-serge

> case of nfsd, however, this is pretty obvious.  So I'm inclined to
> submit the following now (and leave it to be reverted by a later patch
> if CAP_FS_MASK ends up including CAP_MKNOD, as seems likely).
> 
> --b.
> 
> commit 2ec8f8f0c0005ffe3cf93bbf3d9976de76cf4652
> Author: J. Bruce Fields <bfields@citi.umich.edu>
> Date:   Mon Mar 16 18:34:20 2009 -0400
> 
>     nfsd: nfsd should drop CAP_MKNOD for non-root
>     
>     Since creating a device node is normally an operation requiring special
>     privilege, Igor Zhbanov points out that it is surprising (to say the
>     least) that a client can, for example, create a device node on a
>     filesystem exported with root_squash.
>     
>     So, make sure CAP_MKNOD is among the capabilities dropped when an nfsd
>     thread handles a request from a non-root user.
>     
>     Reported-by: Igor Zhbanov <izh1979@gmail.com>
>     Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> 
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index 02bdb76..7824483 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -393,8 +393,10 @@ struct cpu_vfs_cap_data {
>  # define CAP_FULL_SET     ((kernel_cap_t){{ ~0, ~0 }})
>  # define CAP_INIT_EFF_SET ((kernel_cap_t){{ ~CAP_TO_MASK(CAP_SETPCAP), ~0 }})
>  # define CAP_FS_SET       ((kernel_cap_t){{ CAP_FS_MASK_B0, CAP_FS_MASK_B1 } })
> -# define CAP_NFSD_SET     ((kernel_cap_t){{ CAP_FS_MASK_B0|CAP_TO_MASK(CAP_SYS_RESOURCE), \
> -					CAP_FS_MASK_B1 } })
> +# define CAP_NFSD_SET     ((kernel_cap_t){{ CAP_FS_MASK_B0 \
> +					    | CAP_TO_MASK(CAP_SYS_RESOURCE) \
> +					    | CAP_TO_MASK(CAP_MKNOD), \
> +					    CAP_FS_MASK_B1 } })
> 
>  #endif /* _KERNEL_CAPABILITY_U32S != 2 */

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Igor Zhbanov <izh1979@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	neilb@suse.de, Trond.Myklebust@netapp.com,
	David Howells <dhowells@redhat.com>,
	Andrew Morgan <morgan@kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	SELinux <selinux@tycho.nsa.gov>
Subject: Re: Ответ: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK?
Date: Mon, 16 Mar 2009 18:03:42 -0500	[thread overview]
Message-ID: <20090316230342.GB15522@us.ibm.com> (raw)
In-Reply-To: <20090316224848.GC17738@fieldses.org>

Quoting J. Bruce Fields (bfields@fieldses.org):
> Seems this isn't entirely obvious in the general case.  In the specific

I think the MKNOD part is (based on historical behavior as you
suggested) obvious:  both masks should include CAP_MKNOD and
CAP_LINUX_IMMUTABLE.

(references: http://lxr.linux.no/linux-old+v2.0.21/fs/ext2/ioctl.c#L60
for immutable and http://lxr.linux.no/linux-old+v2.0.21/fs/namei.c#L503
for mknod)

-serge

> case of nfsd, however, this is pretty obvious.  So I'm inclined to
> submit the following now (and leave it to be reverted by a later patch
> if CAP_FS_MASK ends up including CAP_MKNOD, as seems likely).
> 
> --b.
> 
> commit 2ec8f8f0c0005ffe3cf93bbf3d9976de76cf4652
> Author: J. Bruce Fields <bfields@citi.umich.edu>
> Date:   Mon Mar 16 18:34:20 2009 -0400
> 
>     nfsd: nfsd should drop CAP_MKNOD for non-root
>     
>     Since creating a device node is normally an operation requiring special
>     privilege, Igor Zhbanov points out that it is surprising (to say the
>     least) that a client can, for example, create a device node on a
>     filesystem exported with root_squash.
>     
>     So, make sure CAP_MKNOD is among the capabilities dropped when an nfsd
>     thread handles a request from a non-root user.
>     
>     Reported-by: Igor Zhbanov <izh1979@gmail.com>
>     Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> 
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index 02bdb76..7824483 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -393,8 +393,10 @@ struct cpu_vfs_cap_data {
>  # define CAP_FULL_SET     ((kernel_cap_t){{ ~0, ~0 }})
>  # define CAP_INIT_EFF_SET ((kernel_cap_t){{ ~CAP_TO_MASK(CAP_SETPCAP), ~0 }})
>  # define CAP_FS_SET       ((kernel_cap_t){{ CAP_FS_MASK_B0, CAP_FS_MASK_B1 } })
> -# define CAP_NFSD_SET     ((kernel_cap_t){{ CAP_FS_MASK_B0|CAP_TO_MASK(CAP_SYS_RESOURCE), \
> -					CAP_FS_MASK_B1 } })
> +# define CAP_NFSD_SET     ((kernel_cap_t){{ CAP_FS_MASK_B0 \
> +					    | CAP_TO_MASK(CAP_SYS_RESOURCE) \
> +					    | CAP_TO_MASK(CAP_MKNOD), \
> +					    CAP_FS_MASK_B1 } })
> 
>  #endif /* _KERNEL_CAPABILITY_U32S != 2 */

  reply	other threads:[~2009-03-16 23:03 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-11 12:53 VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Igor Zhbanov
2009-03-11 23:23 ` J. Bruce Fields
2009-03-12 16:03   ` Serge E. Hallyn
2009-03-12 16:31     ` J. Bruce Fields
2009-03-12 16:10   ` Serge E. Hallyn
2009-03-12 19:00     ` J. Bruce Fields
2009-03-12 20:56       ` Igor Zhbanov
2009-03-12 20:21     ` Michael Kerrisk
2009-03-13 17:58       ` J. Bruce Fields
2009-03-13 18:37         ` Ответ: " Igor Zhbanov
2009-03-13 19:00           ` Serge E. Hallyn
2009-03-13 19:00             ` Serge E. Hallyn
2009-03-16 18:21             ` Stephen Smalley
2009-03-16 18:21               ` Stephen Smalley
2009-03-16 18:49               ` Serge E. Hallyn
2009-03-16 18:49                 ` Serge E. Hallyn
2009-03-16 21:00                 ` Stephen Smalley
2009-03-16 21:00                   ` Stephen Smalley
2009-03-16 22:26                   ` Igor Zhbanov
2009-03-16 23:13                   ` Serge E. Hallyn
2009-03-16 23:13                     ` Serge E. Hallyn
2009-03-16 23:17                     ` Igor Zhbanov
2009-03-17 14:20                     ` Stephen Smalley
2009-03-17 14:20                       ` Stephen Smalley
2009-03-17 17:39                       ` Serge E. Hallyn
2009-03-17 17:39                         ` Serge E. Hallyn
2009-03-17 17:52                         ` Stephen Smalley
2009-03-17 17:52                           ` Stephen Smalley
2009-03-17 18:23                           ` Serge E. Hallyn
2009-03-17 18:23                             ` Serge E. Hallyn
2009-03-18 16:17                             ` ?????: " Casey Schaufler
2009-03-18 16:17                               ` Casey Schaufler
2009-03-18 16:38                               ` Serge E. Hallyn
2009-03-18 16:38                                 ` Serge E. Hallyn
2009-03-18 16:21                             ` Ответ: " Stephen Smalley
2009-03-18 16:21                               ` Stephen Smalley
2009-03-18 16:47                               ` Serge E. Hallyn
2009-03-18 16:47                                 ` Serge E. Hallyn
2009-03-18 16:57                                 ` J. Bruce Fields
2009-03-18 17:24                                   ` Serge E. Hallyn
2009-03-18 17:24                                     ` Serge E. Hallyn
2009-03-16 22:48                 ` J. Bruce Fields
2009-03-16 23:03                   ` Serge E. Hallyn [this message]
2009-03-16 23:03                     ` Serge E. Hallyn
2009-03-14 19:20         ` Michael Kerrisk
2009-03-16 14:16           ` Igor Zhbanov
2009-03-16 16:36             ` J. Bruce Fields
2009-03-16 16:46               ` J. Bruce Fields
2009-03-16 17:05                 ` Serge E. Hallyn
2009-03-16 17:04               ` Serge E. Hallyn
2009-03-16 22:54                 ` J. Bruce Fields
2009-03-16 22:59                   ` Serge E. Hallyn
2009-03-23 13:21                 ` unprivileged mounts vs. rmdir (was: VFS, NFS security bug? ...) Miklos Szeredi
2009-03-26 12:43                   ` Pavel Machek
2009-03-26 13:14                     ` Matthew Wilcox
2009-03-27  7:04                     ` Eric W. Biederman
2009-03-12 11:46 ` VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Igor Zhbanov
     [not found]   ` <f44001920903120446k47590437q95242f7a55c11d57-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-12 12:25     ` Igor Zhbanov

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=20090316230342.GB15522@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=izh1979@gmail.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=neilb@suse.de \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=viro@zeniv.linux.org.uk \
    /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.