On 04/19/2018 04:03 AM, Stefan Berger wrote: > On 04/18/2018 05:32 PM, John Johansen wrote: >> On 04/18/2018 01:12 PM, Eric W. Biederman wrote: >>> Mimi Zohar <[email protected]> writes: >>> >>>> On Wed, 2018-04-18 at 09:09 -0700, John Johansen wrote: >>>>> On 04/13/2018 09:25 AM, Mimi Zohar wrote: >>>>>> [Cc'ing John Johansen] >>>>>> >>>>>> On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote: >>>>>> [...] >>>>>>> As such I expect the best way to create the ima namespace is by simply >>>>>>> writing to securityfs/imafs. Possibly before the user namespace is >>>>>>> even unshared. That would allow IMA to keep track of things from >>>>>>> before a container is created. >>>>> I do think this is generally the right approach for LSMs when looking >>>>> forward to LSM stacking and more LSMs. >>>>> >>>>> >>>>>> My initial thought was to stage IMA namespacing with just IMA-audit >>>>>> first, followed by either IMA-measurement or IMA-appraisal. This >>>>>> would allow us to get the basic IMA namespacing framework working and >>>>>> defer dealing with the securityfs related namespacing of the IMA >>>>>> policy and measurement list issues to later. >>>>>> >>>>>> By tying IMA namespacing to a securityfs ima/unshare file, we would >>>>>> need to address the securityfs issues first. >>>>>> >>>>> well it depends on what you want to do. It would be possible to have >>>>> a simple file (not a jump link) within securityfs that IMA could use >>>>> without having to deal with all the securityfs issues first. However it >>>>> does require that securityfs (not necessarily imafs) be visible within >>>>> the mount namespace of the task doing the setup. >>>> Eric, would you be OK with that? >>> Roughly. My understanding is that you have to have a write to some >>> filesystem to set the ima policy. >>> >>> I was expecting having to write an "create ima namespace" value >>> to the filesystem would not be any special effort. >>> >>> Now it sounds like providing the "create an ima namespace" is going to >>> be a special case, and that does not sound correct. >>> >> not necessarily special case, but they do need to settle on an interface >> that will work for them, and will work with the order they want to land >> things. I was just trying to point out that there are fs solutions that >> can work without having deal with the full securityfs/imafs namespacing >> solution landing first. >> >> While create a file directly in securityfs that lives along side the imafs >> dir. >> ima_create_ns >> ima/ >> does feel like a special case. It could work >> >> what I was thinking of when I proposed a simple is to do it within the ima >> dir, say >> ima/create_ns > > Having looked at SELinux and how Steve does it, I chose 'unshare' as the > filename and put it into the neighborhood of existing IMA securityfs files: > /sys/kernel/security/ima/unshare. Write a '1' to it and you'll have an IMA > namespace upon the next fork()/clone(). > >> >> For now its just a single file but once imafs becomes "virtualized" to a >> namespace view, each dir that imafs jumplinks to contains a instance of the >> file. > > Right. We need to virtualize our IMA securityfs entries pretty soon > afterwards so that we can start setting policies in an IMA namespace. At the > beginning we would not be able to create nested IMA namespaces if a user > namespace is involved. My current patches that attempt to do this basically > implement it by getting out of securityfs for namespace support and hooking > it onto sysfs. On the host we would still use securityfs. > >> >> >> Or they could avoid securityfs/imafs entirely and leverage a file in >> procfs > > If we want to it that way for all other subsystems that do not use a clone() > flag, we should maybe decide on that now... >
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.
