linux-kernel - Re: [RFC] lsm: namespace hooks

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: <1417109911.1805.27.camel@samsung.com>
Date:	Thu, 27 Nov 2014 18:38:31 +0100
From:	Lukasz Pawelczyk <l.pawelczyk@...sung.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Richard Weinberger <richard@....at>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	James Morris <james.l.morris@...cle.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Paul Moore <pmoore@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Nikolay Aleksandrov <nikolay@...hat.com>,
	Mark Rustad <mark.d.rustad@...el.com>,
	David Howells <dhowells@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Juri Lelli <juri.lelli@...il.com>,
	Daeseok Youn <daeseok.youn@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	Dario Faggioli <raistlin@...ux.it>,
	Alex Thorlton <athorlton@....com>,
	Matthew Dempsky <mdempsky@...omium.org>,
	Vladimir Davydov <vdavydov@...allels.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"open list:ABI/API" <linux-api@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Lukasz Pawelczyk <havner@...il.com>
Subject: Re: [RFC] lsm: namespace hooks

On czw, 2014-11-27 at 10:44 -0600, Eric W. Biederman wrote:
> Lukasz Pawelczyk <l.pawelczyk@...sung.com> writes:
> 
> > On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:

> >> We are probably going to need to go a couple rounds with this but at
> >> first approximation I think this functionality needs to be tied to the
> >> user namespace.  This functionality already looks half tied to it.

Actually it's not. You can create LSM/Smack namespace without user
namespace and it works properly.

> >> When mounting filesystems with user namespaces priveleges matures a
> >> little more you should be able to use unmapped labels.  In the near term
> >> we are looking at filesystems such as tmpfs, fuse and posibly extN.

Ok, I get the idea now. But still  think it wouldn't do well with the
Smack namespace. It would basically allow you to operate on something
that the administrator did not allowed you to (by filling the labels'
map).

If the user namespace allows such a thing now I was not aware. I'll have
a look.

> I had two points.
> a) Tie the label mapping to the user namespace, then we don't need any
>    new namespaces.
> 
>    Is there a reason not to tie the label mapping to the user namespace?

I remember that I entertained the idea when I started the work on that
and for some reason went against it.

Right now the major issue I see is that LSM by itself is not defined how
it's going to behave. It's up to a specific LSM module.

E.g. within the Smack namespace filling the map is a privileged
operation. So by tying them up you cripple the ability to create a fully
working user namespace as an unprivileged process.

I want to have Smack namespace be able to map its own label without
privileges (as user namespace can do with its own UID) but for now it's
not the case and I'm not sure it will ever be.

With other LSM implementation other limitations might apply.

Besides a use case (with other LSM modules) when someone might not want
to create an LSM namespace might be valid as well.

> 
>    Needing to modify every userspace that create containers to know
>    about every different lsm looks like a maintenance difficulty I would
>    prefer to avoid.

The LSM namespace is only one, it's not like every LSM modules creates a
different namespace. The LSM namespace is created for the LSM module
that is active at the moment. And user space might need to be aware of
them anyway as e.g. Smack requires you to create labels' map. Other
modules might require something different.

BTW: have you read the Smack-namespace readme I pasted in the cover
letter? It describes the idea behind namespace implementation in that
particular module.

-- 
Lukasz Pawelczyk
Samsung R&D Institute Poland
Samsung Electronics

--
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/