On Wed, Aug 30, 2023 at 07:22:27PM -0400, Paul Moore wrote: Good morning. > On Wed, Aug 30, 2023 at 7:07???PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote: > > > On Wed, Aug 30, 2023 at 6:21???PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Wed, Aug 30, 2023 at 5:50???PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > > > > > > On Wed, Aug 30, 2023 at 4:25???PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > > > > Your initial question was "what happens if the file/filesystem becomes > > > > > > > inaccessible at some point and an attestation client attempts to read > > > > > > > the entire log?". For what reason would it be inaccessible? For the > > > > > > > original single tmpfs file, what would make it inaccessible? > > > > > > > > > > > > In your reply that I had responded to you had mentioned that the > > > > > > kernel was simply being passed a fd and taking ownership of it, the fd > > > > > > could either be a tmpfs backed file or some form of persistent storage > > > > > > as both were discussed in this thread. I imagine a tmpfs filesystem > > > > > > could still be forcibly unmounted, resulting in problems, but I can't > > > > > > say that for certain. However, there are definitely cases where a fd > > > > > > backed against an arbitrary filesystem could run into problems: > > > > > > storage device issues for local filesystems, networking issues for > > > > > > network filesystems, and good old fashioned user/admin intervention in > > > > > > both cases. > > > > > > > > > > "I imagine tmpfs filesystem could still be forcibly unmounted" sounds > > > > > like an attack. Not being able to verify the measurement list against a > > > > > quote is probably a good thing. > > > > > > > > Okay, can you answer the question for an arbitrary persistent > > > > filesystem? That was always the more important question, ... > > > > The original proposal, not mine, suggested using a tmpfs file. The > > idea of writing the measurements to a file on a persistent filesystem > > wasn't mine either. Sush/Tushar were pushing for writing to a > > persistent file(s). No argument from me that writing to a file on an > > arbitrary persistent filesystem is not a good idea. > Progress. Okay, so we all now agree that the kernel writing to an > arbitrary filesystem is not a good idea, and using tmpfs doesn't > solve the problem of general memory pressure (from previously in > this thread), that's all helpful and good to clarify. > > Assuming Sush and Tushar rework the document to clarify the > motivation/purpose for the work, as you suggested earlier, I'm > assuming we can revisit this problem and solutions? IMA will obviously go, with our blessings, in its own direction. I would only call out, as I indicated in my reply to Ken Goldman, that our 20+ year old integrity and attestation architectures and models are now arguably challenged, given emerging technologies and their requirements for integrity and confidentiality. This thread highlights a lot of the issues that caused us to bring TSEM to the table. If we, for the moment, isolate discussion to the growth and/or management of the event log. The architecture of externally modeled namespaces gets the events immediately out of the kernel for a userspace Trusted Modeling Agent (TMA) to deal with, however it chooses. The TMA doesn't even need to be running on the machine itself. We are currently feeding security event streams to entirely different platforms, some hypervisor based, particularly for the training and enforcement of machine learning models. There are obviously concessions that need to be made for LSM event handlers running in atomic context, but that isn't an issue for a security model based simply on file integrity. IMA in atomic context isn't possible, not only from the perspective of doing the file I/O but the need to sleep while the TPM transaction runs. Once again, no criticism of IMA, it is proven and has its own camp and following. From our perspective, and our collaborators, there is an opportunity, and need, to enhance the options available. > paul-moore.com Best wishes for an end of summer holiday weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
