[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87fu3hbhhk.fsf@xmission.com>
Date: Thu, 26 Apr 2018 19:49:59 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc: John Johansen <john.johansen@...onical.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
linux-integrity@...r.kernel.org,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, tycho@...ker.com,
serge@...lyn.com, sunyuqiong1988@...il.com, david.safford@...com,
mkayaalp@...binghamton.edu, James.Bottomley@...senPartnership.com,
Yuqiong Sun <suny@...ibm.com>,
Mehmet Kayaalp <mkayaalp@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support
Stefan Berger <stefanb@...ux.vnet.ibm.com> writes:
> On 04/19/2018 11:35 AM, John Johansen wrote:
>> It sounds like its already decided, with ima and selinux going with an unshare file within their own fs.
>>
>> AppArmor went a different route already, splitting namespace creation (mkdir in the apparmorfs policy/namespace dir) and the task entering the namespace with a write apparmor's equiv of setexeccon.
>>
> I am supporting procfs entries for the IMA namespace spawned by writing a
> boolean '1' into IMA's securityfs 'unshare' file. It would allow to use
> setns(fd, 0), obviously with the 0 parameter. I think this is an important
> function to support considering entering a set of namespace. I am just wondering
> about the 0 parameter. We don't have a CLONE flag for it, so there's not other
> way to support it then. Does it matter ?
That should be fine. We can pick a flag for setns at some point for
IMA. The setns function uses the flag field as an enumeration so any of
the low 8 bits or a combination with overlapping bit is valid to setns.
Eric
Powered by blists - more mailing lists