On 07/15/2015 03:46 PM, Seth Forshee wrote:
> Unprivileged users should not be able to supply security labels
> in filesystems, nor should they be able to supply security
> contexts in unprivileged mounts. For any mount where s_user_ns is
> not init_user_ns, force the use of SECURITY_FS_USE_NONE behavior
> and return EPERM if any contexts are supplied in the mount
> options.
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

I think this is obsoleted by the subsequent discussion, but just for the
record: this patch would cause the files in the userns mount to be left
with the "unlabeled" label, and therefore under typical policies,
completely inaccessible to any process in a confined domain.

> ---
>  security/selinux/hooks.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 459e71ddbc9d..eeb71e45ab82 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -732,6 +732,19 @@ static int selinux_set_mnt_opts(struct super_block *sb,
>           !strcmp(sb->s_type->name, "pstore"))
>               sbsec->flags |= SE_SBGENFS;
>  
> +     /*
> +      * If this is a user namespace mount, no contexts are allowed
> +      * on the command line and security labels mus be ignored.
> +      */
> +     if (sb->s_user_ns != &init_user_ns) {
> +             if (context_sid || fscontext_sid || rootcontext_sid ||
> +                 defcontext_sid)
> +                     return -EPERM;
> +             sbsec->behavior = SECURITY_FS_USE_NONE;
> +             goto out_set_opts;
> +     }
> +
> +
>       if (!sbsec->behavior) {
>               /*
>                * Determine the labeling behavior to use for this
> @@ -813,6 +826,7 @@ static int selinux_set_mnt_opts(struct super_block *sb,
>               sbsec->def_sid = defcontext_sid;
>       }
>  
> +out_set_opts:
>       rc = sb_finish_set_opts(sb);
>  out:
>       mutex_unlock(&sbsec->lock);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to