Message-id: <1417104439.1805.25.camel@samsung.com>
Subject: Re: [RFC] lsm: namespace hooks
From: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
To: "Eric W. Biederman" <ebiederm@xmission.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>
Date: Thu, 27 Nov 2014 17:07:19 +0100
In-reply-to: <87d288zm3a.fsf@x220.int.ebiederm.org>
References: <1417096866-25563-1-git-send-email-l.pawelczyk@samsung.com>
 <1417096866-25563-2-git-send-email-l.pawelczyk@samsung.com>
 <CAFLxGvzw4N4QFv5Vg1dDf9pdRe+Szbevmqn5QNwjLHN4xrokCg@mail.gmail.com>
 <1417098928.1805.15.camel@samsung.com> <54773757.8090905@nod.at>
 <1417099455.1805.17.camel@samsung.com> <54773CE7.5040303@nod.at>
 <1417101060.1805.21.camel@samsung.com> <87d288zm3a.fsf@x220.int.ebiederm.org>
Content-type: text/plain; charset=UTF-8
MIME-version: 1.0
Content-transfer-encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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.


-- 
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/