Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934648AbbGVQO2 (ORCPT ); Wed, 22 Jul 2015 12:14:28 -0400 Received: from mail-oi0-f42.google.com ([209.85.218.42]:33763 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755045AbbGVQO0 (ORCPT ); Wed, 22 Jul 2015 12:14:26 -0400 Date: Wed, 22 Jul 2015 11:14:22 -0500 From: Seth Forshee To: Stephen Smalley Cc: "Eric W. Biederman" , Alexander Viro , Paul Moore , Eric Paris , Serge Hallyn , James Morris , linux-kernel@vger.kernel.org, Andy Lutomirski , linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 6/7] selinux: Ignore security labels on user namespace mounts Message-ID: <20150722161422.GC124342@ubuntu-hedt> References: <1436989569-69582-1-git-send-email-seth.forshee@canonical.com> <1436989569-69582-7-git-send-email-seth.forshee@canonical.com> <55A7B055.4050809@tycho.nsa.gov> <55AFBE85.6010809@tycho.nsa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AFBE85.6010809@tycho.nsa.gov> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1927 Lines: 37 On Wed, Jul 22, 2015 at 12:02:13PM -0400, Stephen Smalley wrote: > On 07/16/2015 09:23 AM, Stephen Smalley wrote: > > 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 > > > > 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. > > The right way to handle this for SELinux would be to automatically use > mountpoint labeling (SECURITY_FS_USE_MNTPOINT, normally set by > specifying a context= mount option), with the sbsec->mntpoint_sid set > from some related object (e.g. the block device file context, as in your > patches for Smack). That will cause SELinux to use that value instead > of any xattr value from the filesystem and will cause attempts by > userspace to set the security.selinux xattr to fail on that filesystem. > That is how SELinux normally deals with untrusted filesystems, except > that it is normally specified as a mount option by a trusted mounting > process, whereas in your case you need to automatically set it. Excellent, thank you for the advice. I'll start on this when I've finished with Smack. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/