On 9/16/2022 3:54 AM, 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? Not everyone is going to know that. And, is it the only capability required to make "things work"? If you call it out in the take message people are going to have a better idea about the relationships between IMA, audit and capabilities. That's pretty important for unprivileged containers.
