On Wed, Feb 3, 2021 at 3:02 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Tue, 2021-02-02 at 10:14 -0800, Raphael Gianotti wrote: > > On 2/2/2021 5:07 AM, Mimi Zohar wrote: > > > On Tue, 2021-02-02 at 07:54 +0200, Amir Goldstein wrote: > > >> On Tue, Feb 2, 2021 at 12:53 AM Raphael Gianotti > > >> <raphgi@xxxxxxxxxxxxxxxxxxx> wrote: > > >>> > > >>> On 1/8/2021 9:58 AM, Raphael Gianotti wrote: > > >>>> On 1/8/2021 4:38 AM, Mimi Zohar wrote: > > >>>>> On Thu, 2021-01-07 at 14:57 -0800, Raphael Gianotti wrote: > > >>>>>>>>>> But this doesn't address where the offloaded measurement list > > >>>>>>>>>> will be stored, how long the list will be retained, nor who > > >>>>>>>>>> guarantees the integrity of the offloaded list. In addition, > > >>>>>>>>>> different form factors will have different requirements. > > >>>>>> For how long the list would be retained, or in the case of a log > > >>>>>> segments, it > > >>>>>> might make sense to have that be an admin decision, something that > > >>>>>> can be > > >>>>>> configured to satisfy the needs of a specific system, as mentioned > > >>>>>> below by > > >>>>>> James, does that seem correct? > > >>>>> For the discussion on exporting and truncating the IMA measurement > > >>>>> list, refer to: > > >>>>> https://lore.kernel.org/linux-integrity/1580998432.5585.411.camel@xxxxxxxxxxxxx/ > > >>>>> > > >>>>> > > >>>>>> Given the possibility of keeping the logs around for an indefinite > > >>>>>> amount of > > >>>>>> time, would using an expansion of the method present in this RFC be > > >>>>>> more > > >>>>>> appropriate than going down the vfs_tmpfile route? Forgive my lack > > >>>>>> on expertise > > >>>>>> on mm, but would the vfs_tmpfile approach work for keeping several > > >>>>>> log segments > > >>>>>> across multiple kexecs? > > >>>>> With the "vfs_tmpfile" mechanism, breaking up and saving the log in > > >>>>> segments isn't needed. The existing mechanism for carrying the > > >>>>> measurement list across kexec would still be used. Currently, if the > > >>>>> kernel cannot allocate the memory needed for carrying the measurement > > >>>>> across kexec, it simply emits an error message, but continues with the > > >>>>> kexec. > > >>>> In this change I had introduced "exporting" the log to disk when the size > > >>>> of the measurement list was too large. Given part of the motivation > > >>>> behind > > >>>> moving the measurement list is the possibility of it growing too large > > >>>> and taking up too much of the kernel memory, that case would likely lead > > >>>> to kexec not being able to carry over the logs. Do you believe it's > > >>>> better > > >>>> to use the "vfs_tmpfile" mechanism for moving the logs to disk and worry > > >>>> about potential issues with kexec not being able to carry over the logs > > >>>> separately, given the "vfs_tempfile" approach seems to be preferred and > > >>>> also simplifies worries regarding truncating the logs? > > >>> After a chat with Mimi I went ahead and did some investigative > > >>> work in the vfs_tmpfile approach suggested, and I wanted to > > >>> restart this thread with some thoughts/questions that came up > > >>> from that. > > >>> For the work I did I simply created a tmp file during ima's > > >>> initialization and then tried to use vm_mmap to map it to memory, > > >>> with the goal of using that memory mapping to generate return > > >>> pointers to the code that writes the measurement entries to memory. > > >> I don't understand why you would want to do that. I might have misunderstood > > >> the requirements, but this was not how I meant for tmpfile to be used. > > >> > > >> Mimi explained to me that currently the IMA measurement list is entirely in > > >> memory and that you are looking for a way to dump it into a file in order to > > >> free up memory. > > >> > > >> What I suggested is this: > > >> > > >> - User opens an O_TMPFILE and passes fd to IMA to start export > > >> - IMA starts writing (exporting) records to that file using *kernel* write API > > >> - Every record written to the file is removed from the in-memory list > > >> - While list is being exported, IMA keeps in-memory count of exported entries > > >> - In ima_measurements_start, if export file exists, start iterator > > >> starts reading > > >> records from the file > > >> - In ima_measurements_next(), when next iterator reaches the export count, > > >> it switches over to iterate in-memory list > > >> > > >> This process can: > > >> 1. Continue forever without maintaining any in-memory list > > >> 2. Work in the background to periodically flush list to file > > >> 3. Controlled by explicit user commands > > >> 4. All of the above > > >> > > >> Is that understood? Did I understand the requirements correctly? > > > > Thanks for the clarification Amir, I never actually saw your initial mails, > > I apologize for the confusion, the use of mmap was something the original > > author of the export ima logs to disk mentioned had been suggested, which > > is why I went down that route. > > Given the actual suggestion you originally had given, I believe the coding > > of it is somewhat to the code I sent in the RFC in terms of approach (if we > > were to have it do periodic flushes, for example). With the addition of > > reads to the log starting with the file as the oldest logs will be there. > > I believe the only difference there is whether the list is kept in a tmp > > file or not, so with the tmp file approach it would be just to keep the > > list out of memory (either partially or permanently), where with a permanent > > file, the list would still be available after a cold boot for instance. > > With Amir's suggestion, userspace still accesses the entire measurement > list via the existing securityfs interface. Only the kernel should be > able to append or access the file. > This user API is not an important part of the suggestion: - User opens an O_TMPFILE and passes fd to IMA to start export It is just how I understood the API should be. Kernel could open the O_TMPFILE or named file for that matter just as well. If the kernel opens an O_TMPFILE, userspace has no standard way to access that file. There are, as always, ways for privileged users to learn about that tmpfile and open it with open_by_handle_at(). IMA is an LSM, so the best way to block unauthorized access to that file would be via LSM hooks. IMA keeps a reference to that file, so it can identify access to that file from userspace. Thanks, Amir.
