On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > > > On a running system, the package installer, after verifying the package > > integrity, would install each file with the associated 'security.ima' > > extended attribute. The 'security.evm' digital signature would be > > installed with an HMAC, calculated using a system unique key. > > The idea isn't to prevent /sbin/kexec from being modified after > installation - it's to prevent it from being possible to install a > system that has a modified /sbin/kexec. Leaving any part of this up to > the package installer means that it doesn't solve the problem we're > trying to solve here. It must be impossible for the kernel to launch any > /sbin/kexec that hasn't been signed by a trusted key that's been built > into the kernel, and it must be impossible for anything other than > /sbin/kexec to make the kexec system call.
I am kind of lost now so just trying to summarize whatever I have learned so far from this thread. - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. So until and unless we have a good solution to verify application's integrity/authneticity at the time of kexec_load() system call we still have the problem. And I don't think we have come up with a solution for that yet (until and unless I missed something). Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
