On Mon, Sep 18, 2023 at 2:00 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Fri, 2023-09-15 at 12:57 +0300, Amir Goldstein wrote: > > > > Assuming IMA is configured, just add "ima_policy=tcb" to the command > > > line. This will measure all files executed, mmap'ed, kernel modules, > > > firmware, and all files opened by root. Normally the builtin policy is > > > replaced with a finer grained one. > > > > > > Below are a few commands, but Ken Goldman is writing documentation - > > > https://ima-doc.readthedocs.io/en/latest/ > > > > > > 1. Display the IMA measurement list: > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements > > > # cat /sys/kernel/security/ima/binary_runtime_measurements > > > > > > 2. Display the IMA policy (or append to the policy) > > > # cat /sys/kernel/security/ima/policy > > > > > > 3. Display number of measurements > > > # cat /sys/kernel/security/ima/runtime_measurements_count > > > > > > > Nice. > > This seems to work fine and nothing pops up when running > > fstests unionmount tests of overlayfs over xfs. > > > > What strikes me as strange is that there are measurements > > of files in xfs and in overlayfs, but no measurements of files in tmpfs. > > I suppose that is because no one can tamper with the storage > > of tmpfs, but following the same logic, nobody can tamper with > > the storage of overlayfs files without tampering with storage of > > underlying fs (e.g. xfs), so measuring overlayfs files should not > > bring any extra security to the system. > > > > Especially, since if files are signed they are signed in the real > > storage (e.g. xfs) and not in overlayfs. > > > > So in theory, we should never ever measure files in the > > "virtual" overlayfs and only measure them in the real fs. > > The only problem is the the IMA hooks when executing, > > mmaping, reading files from overlayfs, don't work on the real fs. > > > > fsnotify also was not working correctly in that respect, because > > fs operations on overlayfs did not always trigger fsnotify events > > on the underlying real fs. > > > > This was fixed in 6.5 by commit bc2473c90fca ("ovl: enable fsnotify > > events on underlying real files") and the file_real_path() infrastructure > > was added to enable this. > > > > This is why I say, that in most likelihood, IMA hook should always use > > file_real_path() and file_dentry() to perform the measurements > > and record the path of the real fs when overlayfs is performing the > > actual read/mmap on the real fs and IMA hooks should ideally > > do nothing at all (as in tmpfs) when the operation is performed > > on the "virtual" overlayfs object. > > tmpfs is excluded from the builtin policy, since there is no way of > storing the file signature in the initramfs (CPIO). There have been a > number of attempts at extending the initramfs CPIO format, but none > have been upstreamed. > > Agreed, IMA should always use the real file for both the lower and the > upper overlayfs. > I took a quick look at some IMA security hooks and I think it's not going to be trivial to fix IMA over overlayfs. Simply adding a bunch of file_real_path() is not going to solve all cases. I still think that my patch is correct, but in order to fix the syzbot crash and other issues, a developer will need to run all the IMA test cases over overlayfs and examine every case more closely. If it is acceptable I would recommend to opt-out of IMA measure/appraise of overlayfs files for the default policy, but that means that underlying real files will not be measure/appraise as well. This way we at least shut up syzbot, because we know that this configuration is broken. Anyway, syzbot has just confirmed that the regressing commit is "IMA: use vfs_getattr_nosec to get the i_version" Thanks, Amir.
