On 9/16/22 06:54, Stefan Berger wrote:
On 9/15/22 20:56, Casey Schaufler wrote:
On 9/15/2022 12:31 PM, Stefan Berger wrote:
The goal of this series of patches is to start with the namespacing of
IMA and support auditing within an IMA namespace (IMA-ns) as the first
step.
In this series the IMA namespace is piggybacking on the user namespace
and therefore an IMA namespace is created when a user namespace is
created, although this is done late when SecurityFS is mounted inside
a user namespace. The advantage of piggybacking on the user namespace
is that the user namespace can provide the keys infrastructure that IMA
appraisal support will need later on.
We chose the goal of supporting auditing within an IMA namespace
since it
requires the least changes to IMA. Following this series, auditing
within
an IMA namespace can be activated by a root running the following lines
that rely on a statically linked busybox to be installed on the host for
execution within the minimal container environment:
As root (since audit rules may now only be set by root):
How about calling out the required capabilities? You don't need
to be root, you need a specific set of capabilities. It would be
very useful for the purposes of understanding the security value
of the patch set to know this.
CAP_AUDIT_WRITE?
Currently the capabilities that are required are CAP_SYS_ADMIN, which I
could change to CAP_AUDIT_WRITE. This would result in the following
change to 26/26:
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index 760e79bb5a34..40cd19d38f23 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1396,15 +1396,15 @@ static unsigned int
ima_parse_appraise_algos(char *arg)
}
/*
- * Either host root with CAP_SYS_ADMIN in current user namespace or
- * root with CAP_SYS_ADMIN on the host entering a namespace may set
+ * Either host root with CAP_AUDIT_WRITE in current user namespace or
+ * root with CAP_AUDIT_WRITE on the host entering a namespace may set
* audit rules inside a namespace.
*/
static bool may_set_audit_rule_in_ns(kuid_t uid, struct user_namespace
*user_ns)
{
return (uid_eq(uid, GLOBAL_ROOT_UID) &&
- ns_capable(user_ns, CAP_SYS_ADMIN))
- || capable(CAP_SYS_ADMIN);
+ ns_capable(user_ns, CAP_AUDIT_WRITE))
+ || capable(CAP_AUDIT_WRITE);
}
static int ima_parse_rule(struct user_namespace *user_ns,
char *rule, struct ima_rule_entry *entry)
What this check is to prevent is that non-root users spawn a user
namespace and set IMA-audit rules which enables them to flood the audit
log. From what I see non-root users have the full capability set in a
user namespace they spawn. So it has to be filtered to root maybe with
CAP_SYS_WRITE instead of CAP_SYS_ADMIN.
