On 11/29/21 09:10, James Bottomley wrote:
On Mon, 2021-11-29 at 08:53 -0500, Stefan Berger wrote:
On 11/29/21 07:50, James Bottomley wrote:
On Sun, 2021-11-28 at 22:58 -0600, Serge E. Hallyn wrote:
On Sat, Nov 27, 2021 at 04:45:49PM +0000, James Bottomley wrote:
Currently we get one entry in the IMA log per unique file
event. So, if you have a measurement policy and it measures a
particular binary it will not get measured again if it is
subsequently executed. For Namespaced IMA, the correct
behaviour
seems to be to log once per inode per namespace (so every
unique
execution in a namespace gets a separate log entry). Since
logging
once per inode per namespace is
I suspect I'll need to do a more in depth reading of the existing
code, but I'll ask the lazy question anyway (since you say "the
correct behavior seems to be") - is it actually important that
files which were appraised under a parent namespace's policy
already
should be logged again?
I think so. For a couple of reasons, assuming the namespace
eventually
gets its own log entries, which the next incremental patch proposed
to
do by virtualizing the securityfs entries. If you don't do this:
To avoid duplicate efforts, an implementation of a virtualized
securityfs is in this series here:
https://github.com/stefanberger/linux-ima-namespaces/commits/v5.15%2Bimans.20211119.v3
It starts with 'securityfs: Prefix global variables with secruityfs_'
That's quite a big patch series. I already actually implemented this
as part of the RFC for getting the per namespace measurement log. The
attached is basically what I did.
I know it's big. I tried to avoid having to bind-mount the system-wide
single securityfs into the container and inherit all the other security
subsystems' files and directories (evm, TPM, safesetid, apparmor, tomoyo
[ https://elixir.bootlin.com/linux/latest/C/ident/securityfs_create_dir
]) and instead have a 'view' that is a bit more restricted to those
subsystems that are namespaced. The securityfs_ns I created can be
mounted into each user namespace individually and only shows what you're
supposed to see without other filesystem tricks to hide files or so. It
should be future-extensible for other subsystem to register themselves
there if they have something to show to the user.
Stefan
