|
From: Mimi Z. <zo...@li...> - 2015-03-23 11:09:25
|
On Sun, 2015-03-22 at 19:00 +0200, Petko Manolov wrote:
> On 15-03-20 08:45:25, Mimi Zohar wrote:
> >
> > The public CA key should be added to the system keyring, not the IMA
> > keyring. Currently the only upstreamed method for adding the public
> CA
> > key to the system keyring is by putting the public CA key, suffixed
> > with .x509, in the kernel's root directory and rebuilding the
> kernel.
> > Fedora has a couple of patches, which have not been upstreamed, that
> add
> > the UEFI/Machine Owner Key(MoK) database keys to the system keyring.
> > Listed below are the main patches, but might introduce some
> dependencies
> > depending on kernel version.
>
> If i read the above correctly the root CA public key must be present
> in the
> kernel's source root at build time.
No, the local-CA public key needs to be loaded on the system keyring,
not just any root CA public key.
> If this is the only restriction i'd rather avoid applying external
> patches to
> the kernel. BTW, is there a way to put various x509 suffixed keys into
> different keyrings when rebuilding the kernel? IOW some of them to go
> to .ima some to .system keyrings?
All the keys in the top directory of the kernel build tree are added to
the system keyring, nothing is added to the IMA keyring.
To view the system keyring, install a recent version of keyutils.
"keyctl show %keyring:.system_keyring"
> > - KEYS: Add a system blacklist keyring
>
> This is, however, of interest to me. Does the kernel support CRLs or
> "blacklist" has some different meaning here?
> > - MODSIGN: Import certificates from UEFI Secure Boot
> > - Add EFI signature data tyeps
> > - Add an EFI signature blob parser and key loader
> These may come handy later on.
These patches add the UEFI/MoK db keys to the system keyring. Without
them, only the builtin keys are on the system keyring.
> > > However, i would need to have CA hierarchy and i wonder whether
> the
> > > current Linux kernel supports it. IOW i need a root certificate to
> > > sign other certificate(s) that on turn will sign IMA keys.
> > > Is it possible to build something like:
> > >
> > >
> > > root CA ------> local CA 1 ------> IMA_key_1
> > > |
> > > +---> local CA 2 ------> IMA_key_2
> > >
> > > So stuff signed by IMA_key_1 and 2 would properly pass the
> appraisal
> > > tests?
> > >
> > >
> > > thanks a bunch,
> >
> > Yes, definitely! Either build the local CA's key into the kernel or
> > import the CA's public key into the MoK db (eg. using mokutil). Use
> > your public CA key to sign the other certificates containing the
> keys to
> > be loaded onto the IMA keyring.
Actually the diagram is a bit different than the one you showed. It
would be:
local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1))
|
|---> IMA_key_2 (signed certificate (eg. selfsigned/CA 2))
> Great, looks like we're all set. However, i thought keyctl/evmctl may
> also import certificates to the IMA keyring?
Right, once a key is signed by the local-CA and the local-CA key is on
the system keyring, use evmctl to load the key onto the .ima keyring.
Mimi
> > Most of the online documentation for signing certificates requires
> > creating a Certificate Signing Request(CSR), which requires the
> private
> > key. There is an OpenSSL option "--ss_cert" that allows signing the
> > certificates directly without access to the private key.
>
> Ah, the pleasure of dealing with openssl's command line parameters. :)
|