On Wed, Jan 16, 2013 at 8:21 PM, Vivek Goyal <vgo...@redhat.com> wrote: > On Wed, Jan 16, 2013 at 12:24:39PM -0500, Mimi Zohar wrote: >> On Wed, 2013-01-16 at 10:54 -0500, Vivek Goyal wrote: >> > On Wed, Jan 16, 2013 at 10:33:11AM -0500, Mimi Zohar wrote: >> > >> > [..] >> > > > - 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. >> > >> > I was going through following presentation. >> > >> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf >> > >> > On slide 8, it mentons signing. >> > >> > evmctl sign --imahash /path/to/file >> > evmctl sign --imasig /path/to/file >> > >> > Can't figure out where does the key for signing come from? Is it already >> > loaded in any of kernel keyrings. >> > >> > If yes, I think this is non-starter. One can not distribute the private >> > key. >> >> No, the default key location is /etc/keys/privkey_evm.pem, but can be >> specified. Prior to Dmitry's updating the package yesterday, the last >> parameter was the key pathname. After the update, you can specify the >> key location with the new --key option. >> >> > Also I am assuming that this is done at installation time? If yes, then >> > again it does not work as installer does not have private key. >> >> Not necessarily. The original use case scenario was creating an image >> with both EVM and IMA digital signatures and then flashing the image. > > But distributions don't ship pre-setup root file system. It is created > and labeled at installation time. So if we want to use IMA, we need to > sign files at installation time. That means private keys need to be > accessible to installer (using --key option). And that does not work for > this use case. > >>
This wrong again.. Private should be used during installation time at all... >> > On slide 11, it talks about importing public keys in kernel keyring from >> > initramfs. As we discussed this will need modification as these keys >> > need to be signed and signing public key should already be part of >> > kernel keyring. >> >> It's been a long process upstreaming all the different pieces involved. >> The initial design/step was to load the public key on a keyring. Since >> then we've added support for multiple keyrings(eg. EVM, IMA, etc). The >> next step is to tie this in with secure boot. >> >> > So looking at the signing process, it really does not look like that >> > I can sign the executable at build server. It looks it needs to be >> > signed by installer at install time and private key needs to be available >> > to installer? >> >> No, the build server can sign the files, so the private key is not >> required on the target. These signatures need to be included in the >> package. Elena Reshetova gave a talk at the last LSS >> (http://lwn.net/Articles/518265/), describing changes to RPM to write >> the security extended attributes. > > Following is from article. > > "The other hooks that Reshetova proposed are associated with the individual > files in a package. Those would allow things like security labeling or > calculating hashes on the file contents (for integrity purposes)." > > IIUC, these hooks will execute on the target. So hash and all signatures > should still be generated on target and not build server? > > Given the fact that signatures are stored in extended attributes, to me > the only way to sign executables in current IMA framework would to be > prepare file system image at build server and ship that image. And > then installer simply mounts that image (after making sure that proper > verification keys have been loaded in kernel). > > And this image will pretty much be static. As you don't have private key > you can't install more packages and sign these. > > So it will be something like one image per signed package (in worst case). > > I don't think starting to ship signed file system images as compared > to signed files is a better idea. > > 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/
