Re: [Linux-ima-user] evm: runaway loop in verify_signature() produce deadlock in process_measurement().

[Mikhail K. <vie...@vi...>]

В Tue, 03 Jan 2017 10:55:37 -0500
Mimi Zohar <zo...@li...> пишет:

> On Tue, 2017-01-03 at 18:02 +0300, Mikhail Kurinnoi wrote:
> > В Tue, 03 Jan 2017 08:42:50 -0500
> > Mimi Zohar <zo...@li...> пишет:
> >   
> > > On Mon, 2017-01-02 at 23:34 +0300, Mikhail Kurinnoi wrote:  
> > > > I switched my tests on another disk and faced with deadlock
> > > > during boot. The deadlock are reproducible if EVM enabled and
> > > > EVM x509 cert is loaded in kernel code (CONFIG_EVM_LOAD_X509)
> > > > with default IMA policy.    
> > > 
> > > These build configuration options are designed to be used in an
> > > environment with a signed init.  If you're not interested in
> > > appraising the init, then wait until you're ready to load the
> > > keys.  
> > 
> > I have this issue if I load cert and EVM keys from initramfs by
> > script with CONFIG_EVM_LOAD_X509 disabled in kernel.
> > 
> > I have no issue with EVM digital signature or HMAC during boot or
> > after boot, I faced with deadlock on switch root only because kernel
> > want to check what crypto-related kernel modules I have installed on
> > real root with /bin/kmod, but, since /bin/kmod also was signed by
> > EVM digital signature, and I could have crypto-related kernel
> > modules installed in real root, kernel call /bin/kmod one more
> > time, but we already have this inode locked in
> > process_measurement()...  
> 
> I lost you here...  If the EVM and IMA keys used to verify /bin/kmod
> are loaded onto their respective keyrings, then there shouldn't be a
> problem.  The verification status result of the first /bin/kmod would
> be cached.

Mimi, the issue not connected to EVM and IMA keys and certs. They all
are loaded onto their respective keyrings for sure. Moreover, this
issue not connected directly to IMA or EVM at all. This is all about 
kernel crypto work, that EVM, probably, should take into account.

What I am trying to explain in another form:
0) IMA/EVM fully loaded and fully functional. Switch to real root.
1) Kernel(IMA/EVM) trying to verify /sbin/init EVM digital signature, call
verify_signature().
2) Kernel(crypto) see rsa+sha1.
3) Kernel(crypto) know, we could have 3 sha1 modules.
4) Kernel(crypto) ask "what sha1 kernel modules we have installed into
system" and call /bin/kmod.
5) Kernel(IMA/EVM) trying to verify /bin/kmod EVM digital signature, call
verify_signature().
6) Kernel(crypto) see rsa+sha1.
7) Kernel(crypto) know, we could have 3 sha1 modules.
8) Kernel(crypto) ask "what sha1 modules we have installed into system"
and call /bin/kmod.
9) Kernel(IMA/EVM) trying to verify /bin/kmod EVM digital signature, wait, 
we already lock /bin/kmod inode in p5.

In my case, kernel have all 3 modules built-in:
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=y
CONFIG_CRYPTO_SHA1_MB=y
but kernel will use /bin/kmod to check installed into system kernel modules 
any way.

This is first verification for /bin/kmod, so, no cache for /bin/kmod
yet. We just now changed the root, we don't have any cache for inodes
in this partition, this is the problem. We can't use /bin/kmod before
EVM verification and we can't verify /bin/kmod EVM signature, since we
need /bin/kmod already verified for this.


-- 
Best regards,
Mikhail Kurinnoi