[PATCH v9 00/23] ima: Namespace IMA with audit support in IMA-ns

[Christian Brauner]

On Tue, Jan 25, 2022 at 05:46:22PM -0500, Stefan Berger wrote:
> From: Stefan Berger <stefanb at linux.ibm.com>
> 
> 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 piggy backing 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 piggy backing 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 user running the following lines
> that rely on a statically linked busybox to be installed on the host for
> execution within the minimal container environment:
> 
> mkdir -p rootfs/{bin,mnt,proc}
> cp /sbin/busybox rootfs/bin
> cp /sbin/busybox rootfs/bin/busybox2
> echo >> rootfs/bin/busybox2
> PATH=/bin unshare --user --map-root-user --mount-proc --pid --fork \
>   --root rootfs busybox sh -c \
>  "busybox mount -t securityfs /mnt /mnt; \
>   busybox echo 1 > /mnt/ima/active; \
>   busybox echo 'audit func=BPRM_CHECK mask=MAY_EXEC' > /mnt/ima/policy; \

I think we need to limit the number of rules that can be added to an ima
namespace to prevent DOS attacks. The current implementation allows
users to write as many ima rules as they want.

My suggestion would be that you look at real-world data to figure out
what a fairly common number of rules is that people write. Then use this
as the hard-coded limit for a first implementation. If the use-case
arises you can later make this limit configurable by introducing a
ucount for ima rules via /proc/sys/user/max_ima_rules.

Additionally, you should probably switch a lot of ima allocations from
GFP_KERNEL to GFP_KERNEL_ACCOUNT as allocations triggerable from userns
should be treated as untrusted.