On Thu, 2018-03-15 at 15:35 -0500, Eric W. Biederman wrote: > Stefan Berger <stefanb@xxxxxxxxxxxxxxxxxx> writes: > > On 03/15/2018 03:20 PM, Eric W. Biederman wrote: [..] > >> From previous conversations I remember that there is a legitimate > >> bootstrap problem for IMA. That needs to be looked at, and I am not > >> seeing that mentioned. > > > > IMA's log should not have a gap. So ideally we shouldn't have to write something > > into sysfs to spawn a new IMA namespace so that we don't miss whatever setup may > > have happened to get there, including the writing into procfs. IMA should be > > there right from the start. So a clone flag would be ideal for that. > > Please make that securityfs not sysfs. Sysfs should be about the > hardware not these higher level software details. I really don't want > to have to namespace sysfs more than I already have. > > As for the no gaps requirement. That is a powerful lever for ruling out > solutions that don't work as well. IMA-measurement and IMA-audit need to be enabled from the very beginning. The only reason we differentiate between IMA-measurement and IMA-audit from IMA-appraisal is simply because the initramfs doesn't include xattrs. Once support for CPIO xattrs is upstreamed, IMA-appraisal could then also be enabled from the very beginning. For now, we rely on the initramfs being measured (and appraised) and enable IMA-appraisal before any files are accessed from real root. Systems with a custom /init today already can enable IMA-appraisal from the very beginning. In terms of IMA namespacing, we shouldn't need to differentiate between IMA-measurement and IMA-audit from IMA-appraisal. All of them should be initialized from the very beginning to capture all measurements in the measurement list, audit the measurements and appraise all files. Requiring IMA namespacing to be joined to another namespace complicates things, like the unnecessary creation of IMA namespaces. Just as there is an "owning" namespace for other namespaces, there should be an "owning" IMA namespace, which is independent of either the mount or user namespace. (I hope I'm using the term "owning" properly here.) Mimi
