Hi Patrick, Zbigniew is out of office today. You should notice, that EVM uses filesystem-specific values (like inode number), so creating valid filesystem on build host machine have to be done little bit more carefully when working with EVM (compared to IMA) when using asymmetric keys. And of course as you said it's not possible to sign image of filesystem on host using EVM HMAC with TPM (trusted) keys. But if you don't have TPM on your platform I think it would be possible to generate EVM HMAC using userspace encrypted keys on host machine, but there's no tools for that.
Have you tried to use EVM with encrypted keys? http://linux-ima.sourceforge.net/evmctl.1.html BR, Janusz > -----Original Message----- > From: Patrick Ohly [mailto:[email protected]] > Sent: Tuesday, May 12, 2015 9:41 PM > To: Zbigniew Jasiński > Cc: [email protected]; [email protected]; 'Tizen Dev'; 'Casey > Schaufler'; 'Whiteman, John L' > Subject: Re: IMA/EVM > > On Tue, 2015-05-12 at 11:50 +0200, Patrick Ohly wrote: > > On Mon, 2015-05-11 at 17:39 +0200, Zbigniew Jasiński wrote: > > > > 2. private key stored on the device and > > > > A. booting with evm=fix or > > > > B. manipulate files only through a process which has > > > > exclusive access to the private key > > > > [...] > > > > > > For option 2A you wanted to add instructions to the Wiki - any > > > > progress for that? > > > > > > > > > > I think tizen.org Wiki 'Sign working device' covers this case. > > > > Okay, so let's talk about that. Which part of that Wiki page describes > > how to teach the kernel about the private key for evm? > > > > It mentions /etc/ima/x509_evm.der, but that is the public key, isn't it? > > > > The suggested kernel config has: > > CONFIG_EVM_KEY_PATH="/etc/ima/evm-key" > > CONFIG_EVM_KMK_PATH="/etc/ima/evm-kmk" > > > > But nothing in the Tizen Wiki explains how to create these files. > > There is > > https://wiki.tizen.org/wiki/Security:IntegrityMeasurement/Using_TPM > > but it describes completely different files. > > > > I'll look at the source next. > > Here's my analysis, please correct me if I got something wrong. > > The x509_evm.der part in the Wiki is about checking checking files signed > with evmctl based on asymmetric keys. That features is experimental and > not yet in upstream Linux. > > The traditional approach depends on a different set of keys, as described in > "Using TPM". These are the keys needed when writing to the file system and > evm is enabled, because they are used by the kernel to calculate the evm > HMAC. evmctl cannot pre-calculate these hashes on a build host; the > approach for signing the system is to run with evm=fix and touching all files. > > The problem that I am running into ("evm: init_desc failed") is caused by only > loading x509_evm.der without those other keys. evm_load_keys() then > enables EVM (evm_initialized |= EVM_STATE_X509_SET, evm_enabled = > evm_fixmode ? EVM_STATE_FIX : EVM_STATE_ENABLED). > > Normally, when > evm_inode_init_security() gets called without EVM enabled, it just returns. > But when EVM is enabled with only the X509 cert, it proceeds and fails > because it misses the keys to create the security.evm xattr. > The same also happens basically everywhere where there's an if check for > "evm_enabled". > > Is just loading x509_evm.der a valid mode of operation? It seems very > reasonable to me (no need for any confidential keys on the device). > > Attached my attempt to make this mode work. It works for me (= can write > files again), but I am concerned that I might have disabled checks too > aggressively (= haven't actually checked appraisal). For example, when a new > file gets created, it has no security.evm, causing > evm_inode_setattr() to reject further changes with EPERM because > evm_verify_current_integrity() fails. Is it really correct to circumvent that > check? > > Either way, my original goal was (and is) to create a fully valid filesystem > in > advance which (at least in theory) could be booted read-only; I don't see > how that can be done with EVM using the official upstream source, so I think > I'll have to postpone work on EVM and keep it disabled. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although I am an > employee of Intel, the statements I make here in no way represent Intel's > position on the issue, nor am I authorized to speak on behalf of Intel on this > matter. > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
