Re: Problem mounting pseudo filesystems with SMACK and IMA enabled.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2018-03-20 at 10:23 +0000, Martin Townsend wrote:
> On Mon, Mar 19, 2018 at 3:47 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 2018-03-19 at 14:37 +0000, Martin Townsend wrote:
> > [...]
> >> The problem was because systemd couldn't create directories for the
> >> mounts /dev/shm and /sys/fs/cgroup/systemd, it was returning -ENOKEY.
> >
> > There's a disconnect between what ima-evm-utils supports and the
> > kernel.  This sounds like the kernel you're using has directory
> > support, which has not been upstreamed.
> >
> >> After investigating it looks like I need to set a key for HMAC to stop
> >> the mkdir failing which I didn't appreciate I needed with a pre-signed
> >> image.
> >
> >> I have a question on this, looking at the IMA code it will try and
> >> replace my signatures with the HMAC unless the immutable attribute is
> >> set, is this correct?
> >
> > EVM will replace the file signature with an HMAC, unless the
> > filesystem is mounted r/o, is immutable, or is signed with the new EVM
> > portable and immutable signature.
> >
> >>  In the evmctl utility there's mention of an evm
> >> immutable flag but I see nothing in the kernel code that supports
> >> this. Is this a feature that never made it into the kernel? or is it
> >> there but I've missed it?
> >
> > The portable and immutable EVM signature is being added only in this
> > release (linux-4.16).
> >
> >> Second question, I have no TPM module so do I need to add a key for
> >> HMAC or is there another way? It's not a problem if I have to add a
> >> key I just want to make 100% sure I have to before patching systemd or
> >> creating my own init process that adds the key before handing over to
> >> systemd.
> >
> > systemd already has support for loading an EVM key.
> >
> > The EVM encrypted key could be based on either a TPM trusted key or a
> > user key, without the HW guarantees of the private key not being
> > exposed in the clear.  If you don't need an EVM key, then without a
> > TPM, you're probably better off backporting the new portable and
> > immutable EVM key.
> 
> I've taken a look at the kernel patch "EVM: Add support for portable
> signature format" and this looks like the exact feature I've been
> looking for :) and it applied fairly cleanly to 4.9 with just a couple
> of easy manual edits.
> 
> I upgraded to the latest 1.1 ima-evm-utils on my host system but I
> can't sign any files with the --portable flag.  (I've added the
> function failing to the log_err function)
> 
> $ LD_LIBRARY_PATH=build/src/.libs sudo ./build/src/.libs/evmctl sign
> --imasig -v -o --generation 0 --uuid  --key

Can you try signing the file without "--generation 0 --uuid"?  Please
provide the output of "getfattr -m ^security -e hex --dump
<filename>".  The security.evm portable and immutable signature should
begin with 0x05.

Mimi


> /ws/rufilla/curtisswright/cwr-signing-authority/ca/ima/inter/private/ima-privkey.pem
> /mnt/ubi/usr/bin/nsenter
> hash: ccb3b93abd61cd1403ce00adbdbc1a75f2d5e9fb
> evm/ima signature: 264 bytes
> 030202a35fd9c60100843c31d91371b691064de4d4f3961d79d5810e24198e18d3b625e75ce8e51cf6a4e45e2fe0e11ab42ac03567952367303d863d978338472fb1689c90fd69524527750e8a0fe39a586f9d24790a45367f2354e9f5bb855e7543f408f4765195ee8d9b81d9bbc4bfed9b5ab16bb8e7a50a45316969c5074c2a213166cbdbc20006b3bb7d721071afdd10cfd9b10e392d8896f67ca3c8391c418515bb3fbfa5c1e0b811a58f394c29be4b73f01804796edee3c84e5fc82e87af1b0a13218de3f2c1e0b328d030291eaab53edd9ffee7ed3febe7e12e4bd26fe36851f095908b03e990548f8759e336987198a55919c7f4333b63630038236fc29df2960d1be1a94a
> generation: 0
> no xattr: security.selinux
> no xattr: security.SMACK64
> name: security.ima, size: 265
> no xattr: security.capability
> sign_evm: calc_evm_hash returned 20
> hash: ad2747d58d06fe7ecf3fea272b68c058c4298941
> evm/ima signature: 264 bytes
> sign_evm: sign_hash returned 264
> 050202a35fd9c601009226f3cba14c00890ea24c0f6bb28176a6e3a7ecadd53a20b7314844c68147e2e8f0d23c15852f88ecb77711518db2431a656434ed9db108ec586ebd1b1343bf1d526e1bb55aab1b9c00cd30619965dc61aae5b9482f6b8bd511cfa098550bc1e65a8541d86ea2f3f01f247dfb219274ab926d905d2bb691e308357e03e8308d3b33e6c0a5f14502a2047679379fce1457529d06665d147cf528b1dd762540574274035d5130f50cc2c14b6a323f4022ce5cbff074230fe8ee81a8b8fad97edec0eae221c6db5272430cf00373c9d50772830729f9eb4473cfb10e7f640daa097a71635548c77f0a96ab91e8c1c0e7b2bfb55588a5fb82a8454f89d7922d96bf
> sign_evm: setxattr security.evm failed: /mnt/ubi/usr/bin/nsenter
> : errno: Operation not permitted (1)
> errno: Operation not permitted (1)
> 
> 
> Yet without --portable it signs the file fine.
> 
> $ LD_LIBRARY_PATH=build/src/.libs sudo ./build/src/.libs/evmctl sign
> --imasig -v --generation 0 --uuid  --key
> /ws/rufilla/curtisswright/cwr-signing-authority/ca/ima/inter/private/ima-privkey.pem
> /mnt/ubi/usr/bin/nsenter
> hash: ccb3b93abd61cd1403ce00adbdbc1a75f2d5e9fb
> evm/ima signature: 264 bytes
> 030202a35fd9c60100843c31d91371b691064de4d4f3961d79d5810e24198e18d3b625e75ce8e51cf6a4e45e2fe0e11ab42ac03567952367303d863d978338472fb1689c90fd69524527750e8a0fe39a586f9d24790a45367f2354e9f5bb855e7543f408f4765195ee8d9b81d9bbc4bfed9b5ab16bb8e7a50a45316969c5074c2a213166cbdbc20006b3bb7d721071afdd10cfd9b10e392d8896f67ca3c8391c418515bb3fbfa5c1e0b811a58f394c29be4b73f01804796edee3c84e5fc82e87af1b0a13218de3f2c1e0b328d030291eaab53edd9ffee7ed3febe7e12e4bd26fe36851f095908b03e990548f8759e336987198a55919c7f4333b63630038236fc29df2960d1be1a94a
> generation: 0
> no xattr: security.selinux
> no xattr: security.SMACK64
> name: security.ima, size: 265
> no xattr: security.capability
> sign_evm: calc_evm_hash returned 20
> hash: d1f22a34a86efc9f15345a39dae2e0c169373d75
> evm/ima signature: 264 bytes
> sign_evm: sign_hash returned 264
> 030202a35fd9c6010001e61de529c455a357de9502fd2d509535dcc43fc42138f27cdcd49d82374dee85504de52599bfb9745a7ec6ad8de49a45bc5691ba8a23d5c0505b247a0397a297b7bc21e9be8b883c2fab86df602b8445fa3d29b7441b5c1de340bf5ee047af0737f707d8228517171eb99d290b9d0aeb1577badb9d2cc44b2b2963ebebb57da4e2b37ce735d7adc9ae82497c9883abcb3b8b5a1a690aaae148e347fbd12cf08e6168868d6588a57523235009ab8ef199627cadbb80eb8fb24dfcb941c28dbe54b80a036dd4c0d2b3d40d4d8ca9c1821e90400e1202ad32343304a80bcd37f5a2616c3790cb6d86ecb0431adf73100a3a163b8fed625711ca10df8ca429d9cf
> 
> 
> I've tried removing various parameters from evmctl but it still fails.
> The only difference I can see in the code path is
> if (evm_portable)
>     sig[0] = EVM_XATTR_PORTABLE_DIGSIG;
> else
>     sig[0] = EVM_IMA_XATTR_DIGSIG;
> 
> before calling lsetxattr, so I followed lsetxattr in the kernel and I
> think it's going to end up at security_inode_setxattr in security.c
> which will then call evm_inode_setxattr which is going to fail on my
> Host PC (Ubuntu 16.04 with a 4.13 kernel ) as it doesn't support this
> new xattr data type:
> 
> if (xattr_data->type != EVM_IMA_XATTR_DIGSIG)
>     return -EPERM;
> 
> Does this sound about right?
> 
> Many Thanks, Martin.
> >
> > Mimi
> >
> 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux