Menu
▾
▴
linux-ima-user
|
From: Petko M. <pe...@nu...> - 2014-09-10 17:48:23
|
On 14-09-10 08:52:28, Mimi Zohar wrote:
>
> Enabling IMA-appraisal is anything but simple. Keys need to be created and files need to be signed (eg. hash/signature). To simplify the process will
> require packages to come with the file signatures included in the packages and installed with the package. Fin Gunter posted the RPM patches. I posted the
> debhelper patches. That is as far as we've gotten.
Yes, i already figured IMA-appraisal can be a tough nut to crack. This is why i started over and tried to do it as simple as possible. Created one RSA keypair
(as per the WIKI) and used it for both IMA and EVM signatures.
The initramdisk i use is squashfs image. When i run the kernel with 'ima_appraise_tcb' it just could not execute /sbin/init. OK, luckily squashfs has got
extended attributes so i quickly hashed (find $RD -type f -exec evmctl ima_hash -a sha256 {} \;) its content and i finally got to the shell prompt. I wonder
how this is handled with 'cpio' archives (or other FS images) without extended attribute support?
The RSA public key is imported as follows:
ima_id=`keyctl newring _ima @u`
evmctl import --rsa /etc/keys/rsa_public.pem $ima_id
evm_id=`keyctl newring _evm @u`
evmctl import --rsa /etc/keys/rsa_public.pem $evm_id
In attempt to keep my setup as simple as possible i used the private RSA key to sign another squashfs image, that is going to be my rootfs with:
evmctl sign --imasig -r --rsa -k $RSA $ROOT
Trying to switch_root into the new root filesystem results in "permission denied"...
Another signing/hashing scheme:
evmctl sign --imahash -u -a sha256 -r --rsa -k $RSA $ROOT
however seems to do the trick. Now i am able to switch_root and do things in the new root FS. Why the first doesn't work while the former does is a bit of
mystery right now. The key is the same, only 'ima' attribute is hash instead of signature. I suspect i should enable IMA/EVM debug messages to get better idea
of what exactly is behind "permission denied".
Once i switch to the new root FS i did some tests to see if the system catches tampering attempts. Since squashfs is read-only i could not alter its content so
i copied a few binaries to /tmp and /var, both of which are mounted RW. /var is loop-mounted ext3 image, btw.
I noticed that adding stuff at the end of a file (like: echo "1234" >> /var/kill) does not prevent the file from execution. However:
dd if=/dev/urandom of=/var/kill bs=1 seek=15000 count=1
results in "permission denied", which i guess is the IMA-appraisal at work. Modifying the same byte of the same binary, but in /tmp resulted in "Segmentation
fault", which seems to be a result of code corruption and not IMA-appraisal actions. I assume both directories somehow have different policies, but i may be
wrong.
I do apologize for the low quality of this post and the abundance of trivial information. I'll try to summarize my questions:
- how the kernel handles ima_appraise_tcb for the initramfs?
- when exactly ima_appraise_tcb kicks in? after loading the appropriate keys or...
- why getting different results with --imasig and --imahash?
- what policies should be put in place to prevent anything that has been changed from execution from any location?
- what should i do to debug kernel's IMA/EVM code? (apart from the obvious ccflags-$(IMA_xxx) += -DDEBUG)
thanks,
Petko
|
|
From: Dmitry K. <d.k...@sa...> - 2014-09-11 14:22:04
|
On 10/09/14 20:08, Petko Manolov wrote:
> On 14-09-10 08:52:28, Mimi Zohar wrote:
>> Enabling IMA-appraisal is anything but simple. Keys need to be created and files need to be signed (eg. hash/signature). To simplify the process will
>> require packages to come with the file signatures included in the packages and installed with the package. Fin Gunter posted the RPM patches. I posted the
>> debhelper patches. That is as far as we've gotten.
> Yes, i already figured IMA-appraisal can be a tough nut to crack. This is why i started over and tried to do it as simple as possible. Created one RSA keypair
> (as per the WIKI) and used it for both IMA and EVM signatures.
>
> The initramdisk i use is squashfs image. When i run the kernel with 'ima_appraise_tcb' it just could not execute /sbin/init. OK, luckily squashfs has got
> extended attributes so i quickly hashed (find $RD -type f -exec evmctl ima_hash -a sha256 {} \;) its content and i finally got to the shell prompt. I wonder
> how this is handled with 'cpio' archives (or other FS images) without extended attribute support?
>
> The RSA public key is imported as follows:
>
> ima_id=`keyctl newring _ima @u`
> evmctl import --rsa /etc/keys/rsa_public.pem $ima_id
>
> evm_id=`keyctl newring _evm @u`
> evmctl import --rsa /etc/keys/rsa_public.pem $evm_id
>
> In attempt to keep my setup as simple as possible i used the private RSA key to sign another squashfs image, that is going to be my rootfs with:
>
> evmctl sign --imasig -r --rsa -k $RSA $ROOT
>
> Trying to switch_root into the new root filesystem results in "permission denied"...
>
> Another signing/hashing scheme:
>
> evmctl sign --imahash -u -a sha256 -r --rsa -k $RSA $ROOT
There 2 main things to understand..
1. Key & signature types.
Signature version 1: use '--rsa' for signing and import. Plain RSA key
is used.
Signature version 2: do not use '--rsa'. You need X509 certificate.
1. EVM version
You have to pay attention to the kernel configuration. It might be
configured to use HMAC version 2 which includes FS UUID.
If it does, you must not use '-u' parameter, because default is to use
FSUUID.
> however seems to do the trick. Now i am able to switch_root and do things in the new root FS. Why the first doesn't work while the former does is a bit of
> mystery right now. The key is the same, only 'ima' attribute is hash instead of signature. I suspect i should enable IMA/EVM debug messages to get better idea
> of what exactly is behind "permission denied".
Your kernel probably is using EVM HMAC v1.
- Dmitry
>
> Once i switch to the new root FS i did some tests to see if the system catches tampering attempts. Since squashfs is read-only i could not alter its content so
> i copied a few binaries to /tmp and /var, both of which are mounted RW. /var is loop-mounted ext3 image, btw.
>
> I noticed that adding stuff at the end of a file (like: echo "1234" >> /var/kill) does not prevent the file from execution. However:
>
> dd if=/dev/urandom of=/var/kill bs=1 seek=15000 count=1
>
> results in "permission denied", which i guess is the IMA-appraisal at work. Modifying the same byte of the same binary, but in /tmp resulted in "Segmentation
> fault", which seems to be a result of code corruption and not IMA-appraisal actions. I assume both directories somehow have different policies, but i may be
> wrong.
>
>
> I do apologize for the low quality of this post and the abundance of trivial information. I'll try to summarize my questions:
>
> - how the kernel handles ima_appraise_tcb for the initramfs?
> - when exactly ima_appraise_tcb kicks in? after loading the appropriate keys or...
> - why getting different results with --imasig and --imahash?
> - what policies should be put in place to prevent anything that has been changed from execution from any location?
> - what should i do to debug kernel's IMA/EVM code? (apart from the obvious ccflags-$(IMA_xxx) += -DDEBUG)
>
>
> thanks,
> Petko
>
|
|
From: Petko M. <pe...@mi...> - 2015-03-20 11:00:17
|
Hello guys,
I am playing with local generated CA that sign public IMA keys. This CA is in the trusted (.ima) keyring and stuff signed by public keys (that are themselves properly signed) seem to work
fine.
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,
Petko
|
|
From: Mimi Z. <zo...@li...> - 2015-03-20 12:46:29
|
On Fri, 2015-03-20 at 12:17 +0200, Petko Manolov wrote: > Hello guys, > > I am playing with local generated CA that sign public IMA keys. This > CA is in the trusted (.ima) keyring and stuff signed by public keys > (that are themselves properly signed) seem to work fine. 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. - KEYS: Add a system blacklist keyring - MODSIGN: Import certificates from UEFI Secure Boot - Add EFI signature data tyeps - Add an EFI signature blob parser and key loader > 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. 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. Good luck! Mimi |
|
From: Mimi Z. <zo...@li...> - 2015-03-20 12:51:12
|
On Fri, 2015-03-20 at 08:45 -0400, Mimi Zohar wrote:
>
> 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.
That should have been: "Use the private CA key".
Mimi
|
|
From: Petko M. <pe...@mi...> - 2015-03-22 17:00:33
|
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. 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? > - 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. > > 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. Great, looks like we're all set. However, i thought keyctl/evmctl may also import certificates to the IMA keyring? > 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. :) Thank you very much, Petko |
|
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. :)
|
|
From: Petko M. <pe...@mi...> - 2015-03-23 14:42:49
|
On 15-03-23 07:00:13, Mimi Zohar wrote:
>
> 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.
Makes sense.
> > > - 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?
Can this blacklist keyring handle certificates as well?
> > > - 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.
Is there a public repository i can checkout these patches from?
> 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))
I've gotten the above to work. The question is, does this make sense:
local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1))
|
|---> local-CA2 (on the .system keyring) ---> IMA_key_3 (signed cert/CA3)
Here local-CA2 (that belongs to trusted entity) is used to sign IMA_key_3 (and possibly others) which on turn IMA signs immutable files.
> 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.
Right. Can the .ima keyring handle CAs or just keys? If it can't then i assume the only option is to get all CAs into the .system keyring and use .ima for keys only.
thanks,
Petko
|
|
From: Mimi Z. <zo...@li...> - 2015-03-23 22:47:58
|
On Mon, 2015-03-23 at 16:43 +0200, Petko Manolov wrote: > On 15-03-23 07:00:13, Mimi Zohar wrote: > > 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)) > > I've gotten the above to work. The question is, does this make sense: > > local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1)) > | > |---> local-CA2 (on the .system keyring) ---> IMA_key_3 (signed cert/CA3) > > Here local-CA2 (that belongs to trusted entity) is used to sign > IMA_key_3 (and possibly others) which on turn IMA signs immutable > files. Assuming you trust all the keys on the system keyring, then any key on the system keyring can verify the certificate. Otherwise, use the "ca_keys=" boot command line option to specify the specific key. Mimi > > 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. > > Right. Can the .ima keyring handle CAs or just keys? If it can't then > i assume the only option is to get all CAs into the .system keyring > and use .ima for keys only. > > thanks, > Petko |
|
From: Petko M. <pe...@mi...> - 2015-03-24 13:35:00
|
On 15-03-23 18:47:43, Mimi Zohar wrote: > On Mon, 2015-03-23 at 16:43 +0200, Petko Manolov wrote: > > > > I've gotten the above to work. The question is, does this make sense: > > > > local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1)) > > | > > |---> local-CA2 (on the .system keyring) ---> IMA_key_3 (signed cert/CA3) > > > > Here local-CA2 (that belongs to trusted entity) is used to sign > > IMA_key_3 (and possibly others) which on turn IMA signs immutable > > files. > > Assuming you trust all the keys on the system keyring, then any key on > the system keyring can verify the certificate. Otherwise, use the > "ca_keys=" boot command line option to specify the specific key. Another useful option, thanks. BTW, where can i download these (MOK related) kernel patches from? Are they public? Petko |
|
From: Mimi Z. <zo...@li...> - 2015-03-25 11:46:13
|
On Tue, 2015-03-24 at 15:35 +0200, Petko Manolov wrote: > On 15-03-23 18:47:43, Mimi Zohar wrote: > > On Mon, 2015-03-23 at 16:43 +0200, Petko Manolov wrote: > > > > > > I've gotten the above to work. The question is, does this make sense: > > > > > > local-CA ----> IMA_key_1 (signed certificate (eg. selfsigned/CA 1)) > > > | > > > |---> local-CA2 (on the .system keyring) ---> IMA_key_3 (signed cert/CA3) > > > > > > Here local-CA2 (that belongs to trusted entity) is used to sign > > > IMA_key_3 (and possibly others) which on turn IMA signs immutable > > > files. > > > > Assuming you trust all the keys on the system keyring, then any key on > > the system keyring can verify the certificate. Otherwise, use the > > "ca_keys=" boot command line option to specify the specific key. > > Another useful option, thanks. > > BTW, where can i download these (MOK related) kernel patches from? Are they public? The original patches were posted on LKML and are available from fedoraproject.org. Mimi |
