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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux