From: ebiederm@xmission.com (Eric W. Biederman)
To: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
Cc: Richard Weinberger <richard@nod.at>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
James Morris <james.l.morris@oracle.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Al Viro <viro@zeniv.linux.org.uk>, Paul Moore <pmoore@redhat.com>,
Kees Cook <keescook@chromium.org>,
Miklos Szeredi <mszeredi@suse.cz>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Nikolay Aleksandrov <nikolay@redhat.com>,
Mark Rustad <mark.d.rustad@intel.com>,
David Howells <dhowells@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Juri Lelli <juri.lelli@gmail.com>,
Daeseok Youn <daeseok.youn@gmail.com>,
David Rientjes <rientjes@google.com>,
Dario Faggioli <raistlin@linux.it>,
Alex Thorlton <athorlton@sgi.com>,
Matthew Dempsky <mdempsky@chromium.org>,
Vladimir Davydov <vdavydov@parallels.com>,
Casey Schaufler <casey@schaufler-ca.com>,
LKML <linux-kernel@vger.kernel.org>,
"open list\:ABI\/API" <linux-api@vger.kernel.org>,
linux-security-module@vger.kernel.org,
Linux Containers <containers@lists.linux-foundation.org>,
Lukasz Pawelczyk <havner@gmail.com>
Subject: Re: [RFC] lsm: namespace hooks
Date: Thu, 27 Nov 2014 10:44:39 -0600 [thread overview]
Message-ID: <871tooy4nc.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <1417104439.1805.25.camel@samsung.com> (Lukasz Pawelczyk's message of "Thu, 27 Nov 2014 17:07:19 +0100")
Lukasz Pawelczyk <l.pawelczyk@samsung.com> writes:
> On czw, 2014-11-27 at 09:42 -0600, Eric W. Biederman wrote:
>> Lukasz Pawelczyk <l.pawelczyk@samsung.com> writes:
>>
>> > On czw, 2014-11-27 at 16:01 +0100, Richard Weinberger wrote:
>> >> Am 27.11.2014 um 15:44 schrieb Lukasz Pawelczyk:
>> >> > True, the last one is 0x80000000. I did not notice that. Thanks for
>> >> > pointing out.
>> >>
>> >> Isn't this CLONE_IO?
>> >
>> > Yes, I was merely noticing out loud that it's the last bit of 32bit.
>> >
>> > After close look though the 0x00001000 appears to be unused
>> >
>> >> > Any suggestion on what can be done here? New syscal with flags2?
>> >>
>> >> I'm not sure. But a new syscall would be a candidate.
>>
>> 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.
>>
>> 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.
>
> I presume you are referring to the Smack namespace readme where I
> mentioned mounts with specifying smack labels in the mount options, not
> to the quote above?
>
> I was referring the to the check here that has been changed to
> smack_ns_privileged() using ns_capable():
> http://lxr.free-electrons.com/source/security/smack/smack_lsm.c#L462
>
> And you can't use an unmapped Smack label inside the namespace, this
> would be completely against its idea.
>
> Anyway, at this point I'm more interested in the LSM namespace. I'll be
> doing an RFC for Smack namespace later.
>
> Unless I misunderstood your mail.
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?
Needing to modify every userspace that create containers to know
about every different lsm looks like a maintenance difficulty I would
prefer to avoid.
b) For filesystems that don't need uid mapping (say ext2 mounted with
user namespace permissions) we shouldn't need LSM mapping either.
Eric
next prev parent reply other threads:[~2014-11-27 16:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 14:01 [RFC] LSM/Smack namespace work in progress Lukasz Pawelczyk
2014-11-27 14:01 ` [RFC] lsm: namespace hooks Lukasz Pawelczyk
2014-11-27 14:18 ` Richard Weinberger
2014-11-27 14:35 ` Lukasz Pawelczyk
[not found] ` <54773757.8090905@nod.at>
2014-11-27 14:44 ` Lukasz Pawelczyk
[not found] ` <54773CE7.5040303@nod.at>
2014-11-27 15:11 ` Lukasz Pawelczyk
[not found] ` <547740A0.4040700@nod.at>
2014-11-27 15:24 ` Lukasz Pawelczyk
2014-11-27 15:42 ` Eric W. Biederman
2014-11-27 16:07 ` Lukasz Pawelczyk
2014-11-27 16:44 ` Eric W. Biederman [this message]
2014-11-27 17:38 ` Lukasz Pawelczyk
2014-12-02 12:43 ` Lukasz Pawelczyk
2014-12-09 16:13 ` Eric W. Biederman
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=871tooy4nc.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=athorlton@sgi.com \
--cc=casey@schaufler-ca.com \
--cc=containers@lists.linux-foundation.org \
--cc=daeseok.youn@gmail.com \
--cc=dhowells@redhat.com \
--cc=havner@gmail.com \
--cc=james.l.morris@oracle.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=juri.lelli@gmail.com \
--cc=keescook@chromium.org \
--cc=l.pawelczyk@samsung.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mark.d.rustad@intel.com \
--cc=mdempsky@chromium.org \
--cc=mingo@redhat.com \
--cc=mszeredi@suse.cz \
--cc=nikolay@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=pmoore@redhat.com \
--cc=raistlin@linux.it \
--cc=richard@nod.at \
--cc=rientjes@google.com \
--cc=serge.hallyn@canonical.com \
--cc=serge@hallyn.com \
--cc=vdavydov@parallels.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox