On 04/19/2018 11:35 AM, John Johansen wrote:
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 <zohar@xxxxxxxxxxxxxxxxxx> 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.
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 ?
Stefan
