| Message ID | 20220125224645.79319-1-stefanb@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ima: Namespace IMA with audit support in IMA-ns | expand |
On Tue, Jan 25, 2022 at 05:46:22PM -0500, Stefan Berger wrote: > From: Stefan Berger <stefanb@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.
On 1/25/22 17:46, Stefan Berger wrote: > From: Stefan Berger <stefanb@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. [...] > > > My tree with these patches is here: > > git fetch https://github.com/stefanberger/linux-ima-namespaces v5.16+imans.v9.posted Thanks a lot for the first round of Ack's, Christian. I haven't looked through all the comments, yet, though. If one pulls this branch one will see that there's a directory STAGE3. This is where I have been storing patches that explore how deep the can is that we are opening here. So yeah, it's pretty deep... In my latest branch I now have 40 patches beyond what we have here that add IMA -measurement support, inheritance of hash algo and IMA template from parent to child, and IMA-appraisal to the IMA namespaces but it doesn't tackle yet all of the issues. At some point it pulls in integrity and EVM for namespacing as well... All 'dimensions of this problem' look good but the patches there are not as clean as we have them here right now. So considering the depth of the problem this may take a while... I also have a test suite just for IMA namespacing that tests IMA-audit in IMA-ns and these upcoming aspects and try to test a lot of things with running many namespace in parallel to test the locking. I run certain tests with up to 1920 namespaces concurrently and so far it's been good, especially with the lock groups from v9 18/23. So don't shake that tree there too hard. https://github.com/stefanberger/ima-namespaces-tests The test suite should be able to skip any tests for which there's no support in Linux. So with this series applied the audit related tests should all work. You can check out the test suite but you may need to move along with my Linux patch branches as I update the test suite. The problem is of course that design changes in Linux patches affect the test suite. So this may cause hiccups. And I have been using forced-updates to solve this issue... The tests have been working on Fedora 34 x86 and ppc64. The unshare tool on Ubuntu 20.04 seems to be too old to run certain tests correctly. Cheers! Stefan
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@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 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.