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:
1. The namespace log will be incomplete in a random way depending on
what execution preceded it. This violates the principle of least
surprise, because you at least expect the IMA log to be consistent
per set of executions.
2. A malicious namespace owner can use the missing information in their
log to infer the execution of others, which is an information leak
IMA tries to prevent by keeping the log readable only by root.
> Since you used the word "log" I'm assuming this isn't building a
> running hash like a tpm pcr where skipping one would invalidate
> rmeote attestation?
Their is only one IMA log, so each entry must be extended through the
PCR to keep the quote correct. That means each per namespace entry
does extend the PCR. However, since the entire entry is logged and the
namespace uuid is part of the entry, the entry hash is different for
each, so the IMA rule about duplicate log entries doesn't apply, if
that was the worry?
James
