Messages in this thread | | | Date | Tue, 7 Dec 2021 10:57:33 -0500 | Subject | Re: [PATCH v3 00/16] ima: Namespace IMA with audit support in IMA-ns | From | Stefan Berger <> |
| |
On 12/7/21 10:17, Christian Brauner wrote:
> On Mon, Dec 06, 2021 at 12:25:44PM -0500, 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 piggy backing on the user namespace >> and therefore an IMA namespace gets created when a user namespace is >> created. The advantage of this 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 >> PATH=/bin unshare --user --map-root-user --mount-proc --pid --fork \ >> --root rootfs busybox sh -c \ >> "busybox mount -t securityfs /mnt /mnt; \ >> busybox echo 'audit func=BPRM_CHECK mask=MAY_EXEC' > /mnt/ima/policy; \ >> busybox cat /mnt/ima/policy" >> >> Following the audit log on the host the last line cat'ing the IMA policy >> inside the namespace would have been audited. Unfortunately the auditing >> line is not distinguishable from one stemming from actions on the host. >> The hope here is that Richard Brigg's container id support for auditing >> would help resolve the problem. >> >> The following lines added to a suitable IMA policy on the host would >> cause the execution of the commands inside the container (by uid 1000) >> to be measured and audited as well on the host, thus leading to two >> auditing messages for the 'busybox cat' above and log entries in IMA's >> system log. >> >> echo -e "measure func=BPRM_CHECK mask=MAY_EXEC uid=1000\n" \ >> "audit func=BPRM_CHECK mask=MAY_EXEC uid=1000\n" \ >> > /sys/kernel/security/ima/policy >> >> The goal of supporting measurement and auditing by the host, of actions >> occurring within IMA namespaces, is that users, particularly root, >> should not be able to evade the host's IMA policy just by spawning >> new IMA namespaces, running programs there, and discarding the namespaces >> again. This is achieved through 'hierarchical processing' of file >> accesses that are evaluated against the policy of the namespace where >> the action occurred and against all namespaces' and their policies leading >> back to the root IMA namespace (init_ima_ns). >> >> The patch series adds support for a virtualized SecurityFS with a few >> new API calls that are used by IMA namespacing. Only the data relevant >> to the IMA namespace are shown. The files and directories of other >> security subsystems (TPM, evm, Tomoyo, safesetid) are not showing >> up when secruityfs is mounted inside a user namespace. >> >> Much of the code leading up to the virtualization of SecurityFS deals >> with moving IMA's variables from various files into the IMA namespace >> structure called 'ima_namespace'. When it comes to determining the >> current IMA namespace I took the approach to get the current IMA >> namespace (get_current_ns()) on the top level and pass the pointer all >> the way down to those functions that now need access to the ima_namespace >> to get to their variables. This later on comes in handy once hierarchical >> processing is implemented in this series where we walk the list of >> namespaces backwards and again need to pass the pointer into functions. >> >> This patch also introduces usage of CAP_MAC_ADMIN to allow access to the >> IMA policy via reduced capabilities. We would again later on use this >> capability to allow users to set file extended attributes for IMA appraisal >> support. >> >> The basis for this series of patches is Linux v5.15. >> My tree with these patches is here: >> https://github.com/stefanberger/linux-ima-namespaces/tree/v5.15%2Bimans.v3.public > I have one small procedural favor to ask. :) > > I couldn't apply your patch series directly. It if isn't too > inconvenient for you could you pass --base with a proper upstream tag, > e.g. --base=v5.15. > > The branch you posted here doesn't exist afaict and I had to peruse your > github repo and figured the correct branch might be v5.15+imans.v3.posted. > > In any case, --base with a proper upstream tag would make this all a bit > easier or - if it really is necessary to pull from your tree it would be > nice if you could post it in a form directly consumable by git and note > url-escaped. So something like > > git clone https://github.com/stefanberger/linux-ima-namespaces v5.15+imans.v3.posted > > would already help.
Sure, will do.
Stefan
> > Christian
| |