On 03/08/2018 03:19 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stefanb@xxxxxxxxxxxxxxxxxx):
On 07/20/2017 06:50 PM, Mehmet Kayaalp wrote:
From: Yuqiong Sun<suny@xxxxxxxxxx>
Add new CONFIG_IMA_NS config option. Let clone() create a new IMA
namespace upon CLONE_NEWNS flag. Add ima_ns data structure in nsproxy.
ima_ns is allocated and freed upon IMA namespace creation and exit.
Currently, the ima_ns contains no useful IMA data but only a dummy
interface. This patch creates the framework for namespacing the different
aspects of IMA (eg. IMA-audit, IMA-measurement, IMA-appraisal).
Signed-off-by: Yuqiong Sun<suny@xxxxxxxxxx>
Changelog:
* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag
* Use existing ima.h headers
* Move the ima_namespace.c to security/integrity/ima/ima_ns.c
* Fix typo INFO->INO
* Each namespace free's itself, removed recursively free'ing
until init_ima_ns from free_ima_ns()
With this patch we would use CLONE_NEWNS and create an IMA and mount
namespace at the same time. However, the code below creates two
inodes to handle the two namespaces separately via setns(). The
... right.
Either the ima and mounts namespaces are so closely tied that ima_ns
should be unshared on every CLONE_NEWNS, or not. If they are, then
every setns(CLONE_NEWNS) must also change the ima_ns. That is not the
case here. Every clone creates a new ima_ns, but we're not forcing
tasks to be in the ima_ns that is matched with its mntns, and
furthermore we have another object lifecycle to worry about.
It still seems to me that the only sane way to do this is to have the
ima_ns be its own object; have it be owned by a user_ns; require
CAP_SYS_ADMIN (or better CAP_MAC_ADMIN) to your current userns to
clone a new one, maybe with no other tasks in userns yet, for good
measure. And support hierarchical measuring (so parents can still
get information about a child's actions).
I think there is a real benefit to keeping the IMA namespace with the
mount namespace since the mount namespace carries the signatures in the
xattrs and IMA the (appraisal) policy. The user namespace has the keys
IMA needs for signature verification and if missing, the appraisal will
fail (at least that is how it could work but Mimi tells me the pointer
to the IMA keyring is cached). So there's an incentive to keep the
otherwise 'loose' namespaces 'together.' If we were to associate the IMA
namespace with the user namespace or be stand-alone, it is easier to
just setns() the mount namespace and circumvent the IMA (appraisal) policy.
If IMA is to be at all trustworthy for remote appraisal, then I do
remote appraisal ? remote attestation ?
not see how you can let a privileged insecure container completely
bypass IMA. The key difference between allowing new ima_ns with
mntns or only with userns is that after unsharing my user_ns, my
privilege with respect to the parent is lost. A new mntns doesn't
change anything about how I can corrupt the parent.
Not quite following. After unsharing the user_ns IMA could be made to
loose access to its keys from the previous user_ns and starting apps
would fail appraisal then, unless the new user_ns IMA keyring has the
same keys again.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
