On Wed, 2013-01-16 at 09:48 -0500, Vivek Goyal wrote: > On Wed, Jan 16, 2013 at 09:00:59AM -0500, Mimi Zohar wrote: > > On Tue, 2013-01-15 at 23:10 -0800, Eric W. Biederman wrote: > > > Mimi Zohar <zo...@linux.vnet.ibm.com> writes: > > > > > > > Please remind me why you can't use IMA-appraisal, which was upstreamed > > > > in Linux 3.7? Why another method is needed? > > > > > > Good question Vivek? > > - IMA did not have any method to lock down signed binary pages in memory. > So while contents on disk could be verified, one could still modify > process memory contents by modifying swap. And IMA does not seem to > have any mechanism to protect against that.
The kernel itself protects executables from being modified by calling try_module_get(). The call to security_bprm_check() is immediately before this call. > - Also I really could not figure out where does the private signing key > lives. I got the impression that we need to trust installer and > signing somehow happens at installation time. And we wanted signing > to happen at build server and could not trust installer for that. Dmitry's ima-evm-utils package signs files. Depending on the options, both the EVM and IMA extended attributes are created. > My understanding of IMA could be wrong. So it would help if you > could list the exact steps about how to achieve the same goal using > IMA. http://linux-ima.sourceforge.net/ needs to be updated, but it describes the integrity subsystem and includes a link to Dave Safford's original whitepaper "An Overview of the Linux Integrity subsystem". > > > > > > I remeber there was a slight mismatch in the desired attributes. In > > > particular we want signatures that are not generated on the local > > > machine. > > > > Right, IMA-appraisal supports different methods of verification. The > > initial methods are hash and digital signature stored in the extended > > attribute. With the queued patches, we can force signature verification > > to be of a specific type. It defines a new IMA policy option called > > 'appraise_type='. > > > > > > With IMA-appraisal, there are a couple of issues that would still need > > > > to be addressed: > > > > - missing the ability to specify the validation method required. > > > > - modify the ima_appraise_tcb policy policy to require elf executables > > > > to be digitally signed. > > > > - security_bprm_check() is called before the binary handler is known. > > > > > > > > The first issue is addressed by a set of patches queued to be upstreamed > > > > in linux-integrity/next-ima-appraise-status. > > > > > > > > To address the last issue would either require moving the existing > > > > bprm_check or defining a new hook after the binary handler is known. > > > > > > Even if there is a small mismatch it certainly sounds like something to > > > investigate. There are a lot of pieces flying around with IMA so an > > > appropriate model of what needs to happen isn't in my head. As opposed > > > to a signature in an ELF executable and a key in the kernel. > > > > The original IMA was about measurement and attestation. IMA-appraisal > > adds local integrity validation and enforcement of the measurement > > against a "good" value stored as an extended attribute 'security.ima'. > > The initial methods for validating 'security.ima' are hash and digital > > signature based. > > > > > Hooks aside in an IMA world where does the signing key live? Where does > > > the signature live? > > > > Initially, the public key used to verify the signature is loaded onto an > > IMA specific keyring. We've discussed embedding public keys inside the > > kernel, but haven't done so yet. > > So where does the signing key (private key) live? And when does actual > signing happens and who does it. The signing process is currently not part of kbuild, but a separate process, as mentioned above. > > > > The next steps are to ensure the secure boot signature chain of trust > > has not been broken. > > Yes this one is important. This will also include making sure root can > not load/install its own keys until and unless new key is signed with > one of existing keys. Otherwise chain of trust is broken. Right. thanks, Mimi -- 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/
