linux-kernel - Re: [PATCH 0/7] Initial support for user namespace owned mounts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87fv4nr6dh.fsf@x220.int.ebiederm.org>
Date:	Thu, 16 Jul 2015 19:10:34 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Lukasz Pawelczyk <l.pawelczyk@...sung.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Andy Lutomirski <luto@...capital.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts

Lukasz Pawelczyk <l.pawelczyk@...sung.com> writes:

> On śro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote:
>> 
>> I am on the fence with Lukasz Pawelczyk's patches.  Some parts I 
>> liked
>> some parts I had issues with.  As I recall one of my issues was that
>> those patches conflicted in detail if not in principle with this
>> appropach.
>> 
>> If these patches do not do a good job of laying the ground work for
>> supporting security labels that unprivileged users can set than Seth
>> could really use some feedback.  Figuring out how to properly deal 
>> with
>> the LSMs has been one of his challenges.
>
> I fail to see how those 2 are in any conflict. 

Like I said.  They don't really conflict, and actually to really support
things well for smack we probably need something like your patches.

At the same time a patch written without dealing with s_user_ns is going
to going to fail to take a lot of important details into account.

Right now after fixing the mount namespace issues the top priority is to
work through the details and get s_user_ns implemented.  By that I mean
some version of patch 1 of Seth's series.

s_user_ns fundamentally changes how the concepts are represented in the
kernel in a way that is easier to secure, and that fundamentally better
matches things.  And sigh.  This review has shown we don't quite have
all of the details worked out.

> If your approach here is to treat user ns mounted filesystem as if they
> didn't support xattrs at all then my patches don't conflict here any
> more than Smack itself already does.

The end game if people developing smack choose to play, is to figure out
how to store your unmapped labels in a filesystem contained by a
user namespace and a smack label namespace root.

> If the filesystem will get a default (e.g. by smack* mount options)
> label then this label will co-work with Smack namespaces.

A default, but I don't know if it will be smack mount options that will
give that default.  The devil is in the details and there are a lot
of details.

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