On Friday, 16 September 2022 15:36:52 AEST Ken Williams wrote: > If yes, then let me describe my environment; > I am running an older kernel, 4.14.238, Things are changing all the time in IMA, getting an older kernel to work might be a problem. However I have seen some documentation about using it in embedded systems in vehicles which is a use that tends to have long support times, so some old versions will be supported. > learning curve in this area may not be out of line. My plan is to > pre-sign the files prior to installation and I see that effort as > being outside of the scope of my inquiries here. So now, does it look > like I am starting in the right direction? For typical uses of Linux you would want pre-signed executables. You want to have the system running the programs to not have the signing key and provide the signatures from a trusted system. I've been thinking of having some sort of system that proxies the packages of software and creates signatures for them. The default signing includes the Inode number of the file, that can be disabled or the system installing could say "give me a signature for /bin/bash from package bash version 5.2~rc2-2 with Inode 27597791". The next issue is that the current kernel code doesn't allow signing unsigned files unless you boot with "ima_appraise=fix evm=fix" on the kernel command- line. I've been thinking of writing a kernel patch to give a compile time option to remove that requirement. As for reasons to use IMA without TPM, one example is virtual machines. The host OS provides a known good kernel and initramfs and we want that kernel to ensure that it's not running a corrupt user-space. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
