Re: [RFC 08/20] ima: Move measurement list related variables into ima_namespace

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

 




On 12/2/21 07:46, James Bottomley wrote:
On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
Move measurement list related variables into the ima_namespace. This
way a
front-end like SecurityFS can show the measurement list inside an IMA
namespace.

Implement ima_free_measurements() to free a list of measurements
and call it when an IMA namespace is deleted.
This one worries me quite a lot.  What seems to be happening in this
code:

@@ -107,7 +100,7 @@ static int ima_add_digest_entry(struct
ima_namespace *ns,
         qe->entry = entry;
INIT_LIST_HEAD(&qe->later);
-       list_add_tail_rcu(&qe->later, &ima_measurements);
+       list_add_tail_rcu(&qe->later, &ns->ima_measurements);
atomic_long_inc(&ns->ima_htable.len);
         if (update_htable) {

is that we now only add the measurements to the namespace list, but
that list is freed when the namespace dies.  However, the measurement
is still extended through the PCRs meaning we have incomplete
information for a replay after the namespace dies?

*Not at all.* The measurement list of the namespace is independent of the host.

The cover letter states:

"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   "

So even now, with only auditing support in the namespace, you would get measurements in the host log with an appropriately written IMA policy. The measurements in the host log won't go away when the namespace dies.

The intention is to provide flexibility that allows for writing the IMA policy of the host in such a way

- that file accesses occurring in namespaces get measured on the host

- that file accesses occurring in the namespace do NOT get measured on the host and protect the host log from ever growing or actions in namespaces intentionally growing the host log

There would be a namespace policy that would allow for logging inside the namespace. Combine this with the policy on the host and you can have no measurements of the namespace file access, measurements in either the host log or the namespace log or both. What I would be worried about is if the flexibility wasn't there.



I tend to think the way this should work is that until we have a way of
attesting inside the namespace, all measurements should go into the
physical log, so that replay is always complete for the PCRs, so
effectively the visible log of the namespace would always have to be a
subset of the physical log.

Per the cover letter description this is already possible today.

   Stefan



James





[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