On 1/26/22 08:19, Christian Brauner wrote:
On Tue, Jan 25, 2022 at 05:46:22PM -0500, Stefan Berger wrote:From: Stefan Berger <stefanb@xxxxxxxxxxxxx> 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
I would now go with a hard-coded (generous) limit of 1024 rules for non-init_ima_ns, and leave init_ima_ns unbounded.
arises you can later make this limit configurable by introducing a ucount for ima rules via /proc/sys/user/max_ima_rules.
Ok, let's defer this.
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.
Ok, done.
