linux-ima-user — Q&A for users of IMA

Re: [Linux-ima-user] no ima or tpm0 measurements

[Mimi Z. <zo...@li...>]

On Wed, 2013-09-25 at 17:10 +0200, Nicolae Paladi wrote:
> On 25 September 2013 16:52, Mimi Zohar <zo...@li...> wrote:
> 
> > On Wed, 2013-09-25 at 14:33 +0200, Nicolae Paladi wrote:
> > > Hi,
> > >
> > > I'm using a CentOS 6.4 platform with the 2.6.32 kernel;
> > >
> > > I boot with the following arguments:
> > >
> > > ro root=/dev/mapper/myhost-root rd_NO_LUKS rd_LVM_LV=myhost/root
> > > LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=sv-latin1 rd_NO_MD
> > SYSFONT=lata
> > > rcyrheb-sun16 ima_tcb ima=on crashkernel=129M@0M rd_NO_DM rhgb quiet
> > >
> > > tpm_version show the following:
> > >  TPM 1.2 Version Info:
> > > Chip Version:        1.2.8.28
> > > Spec Level:          2
> > > Errata Revision:     3
> > > TPM Vendor ID:       STM
> > > TPM Version:         01010000
> > >
> > >
> > > However, there is no output in the /sys/kernel/security/ directory;
> > > The BIOS settings are correct since there WAS an expected output when
> > > I was running on a Ubuntu platform.
> > >
> > > Am I badly missing something here? Or is this a bug?
> > >
> > > Thank you,
> > > /Nico
> >
> > Make sure the TPM is builtin, not as a module, and IMA,EVM are enabled.
> >
> > IMA is enabled, as far as I see:
> 
> cat /usr/src/kernels/2.6.32-358.118.1.openstack.el6.x86_64/.config | grep
> CONFIG_IMA
> CONFIG_IMA=y
> CONFIG_IMA_MEASURE_PCR_IDX=10
> CONFIG_IMA_AUDIT=y
> CONFIG_IMA_LSM_RULES=y
> 
> How can I see that the TPM is 'builtin'? The machine was shipped with the
> TPM, it's a dell rack server;

Check that 'CONFIG_TCG_TPM=y' is enabled.

Even without the TPM enabled, there should be a measurement list.
'ima_tcb' is the only boot command line parameter needed.  (Try removing
ima=on.)

thanks,

Mimi

Re: [Linux-ima-user] no ima or tpm0 measurements

[Nicolae P. <n.p...@gm...>]

On 25 September 2013 16:52, Mimi Zohar <zo...@li...> wrote:

> On Wed, 2013-09-25 at 14:33 +0200, Nicolae Paladi wrote:
> > Hi,
> >
> > I'm using a CentOS 6.4 platform with the 2.6.32 kernel;
> >
> > I boot with the following arguments:
> >
> > ro root=/dev/mapper/myhost-root rd_NO_LUKS rd_LVM_LV=myhost/root
> > LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=sv-latin1 rd_NO_MD
> SYSFONT=lata
> > rcyrheb-sun16 ima_tcb ima=on crashkernel=129M@0M rd_NO_DM rhgb quiet
> >
> > tpm_version show the following:
> >  TPM 1.2 Version Info:
> > Chip Version:        1.2.8.28
> > Spec Level:          2
> > Errata Revision:     3
> > TPM Vendor ID:       STM
> > TPM Version:         01010000
> >
> >
> > However, there is no output in the /sys/kernel/security/ directory;
> > The BIOS settings are correct since there WAS an expected output when
> > I was running on a Ubuntu platform.
> >
> > Am I badly missing something here? Or is this a bug?
> >
> > Thank you,
> > /Nico
>
> Make sure the TPM is builtin, not as a module, and IMA,EVM are enabled.
>
> IMA is enabled, as far as I see:

cat /usr/src/kernels/2.6.32-358.118.1.openstack.el6.x86_64/.config | grep
CONFIG_IMA
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_AUDIT=y
CONFIG_IMA_LSM_RULES=y

How can I see that the TPM is 'builtin'? The machine was shipped with the
TPM, it's a dell rack server;

Mimi
>

Re: [Linux-ima-user] no ima or tpm0 measurements

[Mimi Z. <zo...@li...>]

On Wed, 2013-09-25 at 14:33 +0200, Nicolae Paladi wrote:
> Hi,
> 
> I'm using a CentOS 6.4 platform with the 2.6.32 kernel;
> 
> I boot with the following arguments:
> 
> ro root=/dev/mapper/myhost-root rd_NO_LUKS rd_LVM_LV=myhost/root
> LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=sv-latin1 rd_NO_MD SYSFONT=lata
> rcyrheb-sun16 ima_tcb ima=on crashkernel=129M@0M rd_NO_DM rhgb quiet
> 
> tpm_version show the following:
>  TPM 1.2 Version Info:
> Chip Version:        1.2.8.28
> Spec Level:          2
> Errata Revision:     3
> TPM Vendor ID:       STM
> TPM Version:         01010000
> 
> 
> However, there is no output in the /sys/kernel/security/ directory;
> The BIOS settings are correct since there WAS an expected output when
> I was running on a Ubuntu platform.
> 
> Am I badly missing something here? Or is this a bug?
> 
> Thank you,
> /Nico

Make sure the TPM is builtin, not as a module, and IMA,EVM are enabled.

Mimi

[Linux-ima-user] no ima or tpm0 measurements

[Nicolae P. <n.p...@gm...>]

Hi,

I'm using a CentOS 6.4 platform with the 2.6.32 kernel;

I boot with the following arguments:

ro root=/dev/mapper/myhost-root rd_NO_LUKS rd_LVM_LV=myhost/root
LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=sv-latin1 rd_NO_MD SYSFONT=lata
rcyrheb-sun16 ima_tcb ima=on crashkernel=129M@0M rd_NO_DM rhgb quiet

tpm_version show the following:
 TPM 1.2 Version Info:
Chip Version:        1.2.8.28
Spec Level:          2
Errata Revision:     3
TPM Vendor ID:       STM
TPM Version:         01010000


However, there is no output in the /sys/kernel/security/ directory;
The BIOS settings are correct since there WAS an expected output when
I was running on a Ubuntu platform.

Am I badly missing something here? Or is this a bug?

Thank you,
/Nico

Re: [Linux-ima-user] EVM hash / Permission Denied / Invalid HMAC

[JL_N_ <dar...@gm...>]

Ok everything solved :) , Thank you for support


2013/8/6 Mimi Zohar <zo...@li...>

> On Tue, 2013-08-06 at 16:32 +0200, JL_N_ wrote:
> > Then have you any Idea why .evm is lost after reboot ?
> >
> > PS: last message, forgot to join mailing list sorry
> > --------------------------
> > CONFIG_EVM_HMAC_VERSION=2 -> thanks that solved me the problem with using
> > -u when creating evmctl
> > I'm wondering if my config works well ...
> > I create a script file
> >
> > root@bt:~/Desktop# getfattr -m . -d test.sh
> > # file: test.sh
> > security.evm=0x0209d445f479df7502820651291221beb7029d982c
> > security.ima=0x0174e66832f8a97698ca7b44c036eb39ca00ac5d7a
> >
> >
> > I sign with your command
> > root@bt:~/Desktop# evmctl sign -u - -x --imasig test.sh
> > # file: test.sh
> >
> security.evm=0x0302025e61f96500808ba2575fd577b9c31edf1ca994bddd16ab6395402c2bd4c7b8b6d5f8cc948114afc7ba6b06180f433c1f4060fcf0c00002ce26b27d1dbeba1302356fa89969e416444bf60caeaf4f18dd8247e214f1b21f17ce3444ec9addb6a088efa0f24face99ff7ef1d5c664fcaabe887261851507fabe1562ec9942cbb632e4ab1ac6180
> >
> security.ima=0x0302025e61f965008069138b19c5be04b27eb95fa9d27ff49f6565630217bbee3e368f37915f92114c9d4343a8508ef0c5e2a3f8bfaecb0ff10130647d4cb50f8d04a147fbb41b5d798f35ee4ed2fba072336d381529375b0ad84e3dd39c93867d9fb24ca9d9fab42945b29a296189c142a5cfed77fde8fa9e85934de2b908749903159fd81d634ffc
> >
> >
> > I REBOOT
> >
> > Script still executable but I lost .evm signature ???
> >
> > root@bt:~/Desktop# getfattr -m . -e hex -d great.sh
> > # file: test.sh
> > security.evm=0x02c7728ccbad9f579e9219c2acbf0cb34a2a41650b
> >
> security.ima=0x0302025e61f965008069138b19c5be04b27eb95fa9d27ff49f6565630217bbee3e368f37915f92114c9d4343a8508ef0c5e2a3f8bfaecb0ff10130647d4cb50f8d04a147fbb41b5d798f35ee4ed2fba072336d381529375b0ad84e3dd39c93867d9fb24ca9d9fab42945b29a296189c142a5cfed77fde8fa9e85934de2b908749903159fd81d634ffc
> >
> >
> > .ima works very well with enforce mode (i did a test tryng to echo
> > "aaa">>test.sh gives Permission denied).
> > But .evm looks lost ... is it normal ?
>
> At some point, we might want to revisit this decision.  At least for
> now, replacing the 'security.evm' signature with an HMAC, is normal
> behavior.
>
> Mimi
>
>

Re: [Linux-ima-user] EVM hash / Permission Denied / Invalid HMAC

[Mimi Z. <zo...@li...>]

On Tue, 2013-08-06 at 16:32 +0200, JL_N_ wrote:
> Then have you any Idea why .evm is lost after reboot ?
> 
> PS: last message, forgot to join mailing list sorry
> --------------------------
> CONFIG_EVM_HMAC_VERSION=2 -> thanks that solved me the problem with using
> -u when creating evmctl
> I'm wondering if my config works well ...
> I create a script file
> 
> root@bt:~/Desktop# getfattr -m . -d test.sh
> # file: test.sh
> security.evm=0x0209d445f479df7502820651291221beb7029d982c
> security.ima=0x0174e66832f8a97698ca7b44c036eb39ca00ac5d7a
> 
> 
> I sign with your command
> root@bt:~/Desktop# evmctl sign -u - -x --imasig test.sh
> # file: test.sh
> security.evm=0x0302025e61f96500808ba2575fd577b9c31edf1ca994bddd16ab6395402c2bd4c7b8b6d5f8cc948114afc7ba6b06180f433c1f4060fcf0c00002ce26b27d1dbeba1302356fa89969e416444bf60caeaf4f18dd8247e214f1b21f17ce3444ec9addb6a088efa0f24face99ff7ef1d5c664fcaabe887261851507fabe1562ec9942cbb632e4ab1ac6180
> security.ima=0x0302025e61f965008069138b19c5be04b27eb95fa9d27ff49f6565630217bbee3e368f37915f92114c9d4343a8508ef0c5e2a3f8bfaecb0ff10130647d4cb50f8d04a147fbb41b5d798f35ee4ed2fba072336d381529375b0ad84e3dd39c93867d9fb24ca9d9fab42945b29a296189c142a5cfed77fde8fa9e85934de2b908749903159fd81d634ffc
> 
> 
> I REBOOT
> 
> Script still executable but I lost .evm signature ???
> 
> root@bt:~/Desktop# getfattr -m . -e hex -d great.sh
> # file: test.sh
> security.evm=0x02c7728ccbad9f579e9219c2acbf0cb34a2a41650b
> security.ima=0x0302025e61f965008069138b19c5be04b27eb95fa9d27ff49f6565630217bbee3e368f37915f92114c9d4343a8508ef0c5e2a3f8bfaecb0ff10130647d4cb50f8d04a147fbb41b5d798f35ee4ed2fba072336d381529375b0ad84e3dd39c93867d9fb24ca9d9fab42945b29a296189c142a5cfed77fde8fa9e85934de2b908749903159fd81d634ffc
> 
> 
> .ima works very well with enforce mode (i did a test tryng to echo
> "aaa">>test.sh gives Permission denied).
> But .evm looks lost ... is it normal ?

At some point, we might want to revisit this decision.  At least for
now, replacing the 'security.evm' signature with an HMAC, is normal
behavior. 
 
Mimi

Re: [Linux-ima-user] EVM hash / Permission Denied / Invalid HMAC

[JL_N_ <dar...@gm...>]

Then have you any Idea why .evm is lost after reboot ?

PS: last message, forgot to join mailing list sorry
--------------------------
CONFIG_EVM_HMAC_VERSION=2 -> thanks that solved me the problem with using
-u when creating evmctl
I'm wondering if my config works well ...
I create a script file

root@bt:~/Desktop# getfattr -m . -d test.sh
# file: test.sh
security.evm=0x0209d445f479df7502820651291221beb7029d982c
security.ima=0x0174e66832f8a97698ca7b44c036eb39ca00ac5d7a


I sign with your command
root@bt:~/Desktop# evmctl sign -u - -x --imasig test.sh
# file: test.sh
security.evm=0x0302025e61f96500808ba2575fd577b9c31edf1ca994bddd16ab6395402c2bd4c7b8b6d5f8cc948114afc7ba6b06180f433c1f4060fcf0c00002ce26b27d1dbeba1302356fa89969e416444bf60caeaf4f18dd8247e214f1b21f17ce3444ec9addb6a088efa0f24face99ff7ef1d5c664fcaabe887261851507fabe1562ec9942cbb632e4ab1ac6180
security.ima=0x0302025e61f965008069138b19c5be04b27eb95fa9d27ff49f6565630217bbee3e368f37915f92114c9d4343a8508ef0c5e2a3f8bfaecb0ff10130647d4cb50f8d04a147fbb41b5d798f35ee4ed2fba072336d381529375b0ad84e3dd39c93867d9fb24ca9d9fab42945b29a296189c142a5cfed77fde8fa9e85934de2b908749903159fd81d634ffc


I REBOOT

Script still executable but I lost .evm signature ???

root@bt:~/Desktop# getfattr -m . -e hex -d great.sh
# file: test.sh
security.evm=0x02c7728ccbad9f579e9219c2acbf0cb34a2a41650b
security.ima=0x0302025e61f965008069138b19c5be04b27eb95fa9d27ff49f6565630217bbee3e368f37915f92114c9d4343a8508ef0c5e2a3f8bfaecb0ff10130647d4cb50f8d04a147fbb41b5d798f35ee4ed2fba072336d381529375b0ad84e3dd39c93867d9fb24ca9d9fab42945b29a296189c142a5cfed77fde8fa9e85934de2b908749903159fd81d634ffc


.ima works very well with enforce mode (i did a test tryng to echo
"aaa">>test.sh gives Permission denied).
But .evm looks lost ... is it normal ?

Re: [Linux-ima-user] EVM hash / Permission Denied / Invalid HMAC

[Mimi Z. <zo...@li...>]

On Sat, 2013-08-03 at 23:38 +0200, JL_N_ wrote:
> I am trying to activate IMA appraisal & EVM modules.
> 
> After compiling linux kernel 3.10.2 on my bt5R3 and setting kernel boot
> option in a first time like this:
> 
> GRUB_CMDLINE_LINUX="rootflags=i_version ima_tcb ima_appraise=fix
> ima_appraise_tcb evm=fix"
> 
> and after running this command to generate xattr security.ima and
> security.evm
> 
> find / \( -fstype rootfs -o -fstype ext4 \) -type f -uid 0 -exec head
> -c 1 '{}' \;
> 
> like this:
> 
> GRUB_CMDLINE_LINUX="rootflags=i_version ima_tcb ima_appraise=enforce
> ima_appraise_tcb evm=enforce"

At this point, the filesystem should be labeled properly. 'security.ima'
should contain hashes. 'security.evm' should contain hmac.

> I try to create digital signature of xattr like it's recommended on
> tutorial Tutorial to IMA &
> EVM<http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page>
> .
> Seems to work for immutable file with IMA but not for EVM.
> 
> evmctl sign -u - -x --imahash new.sh

'security.ima' should still contain a hash. 'security.evm' should
contain a signature.  To view the extended attributes, use the getfattr
'-e hex' option.

> Gives Permission Denied when I reboot and try to launch
> But when I use

The public key needs to be loaded on reboot.  Have you modified the
initramfs to load the public key on the _evm keyring?  (and on the _ima
keyring, if you signed with the '--imasig' option.)

To verify the public key is loaded properly on the _evm keyring, execute
as root:  keyctl show `keyctl search @u keyring _evm`

Mimi

[Linux-ima-user] EVM hash / Permission Denied / Invalid HMAC

[JL_N_ <dar...@gm...>]

I am trying to activate IMA appraisal & EVM modules.

After compiling linux kernel 3.10.2 on my bt5R3 and setting kernel boot
option in a first time like this:

GRUB_CMDLINE_LINUX="rootflags=i_version ima_tcb ima_appraise=fix
ima_appraise_tcb evm=fix"

and after running this command to generate xattr security.ima and
security.evm

find / \( -fstype rootfs -o -fstype ext4 \) -type f -uid 0 -exec head
-c 1 '{}' \;

like this:

GRUB_CMDLINE_LINUX="rootflags=i_version ima_tcb ima_appraise=enforce
ima_appraise_tcb evm=enforce"

I try to create digital signature of xattr like it's recommended on
tutorial Tutorial to IMA &
EVM<http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page>
.
Seems to work for immutable file with IMA but not for EVM.

evmctl sign -u - -x --imahash new.sh

Gives Permission Denied when I reboot and try to launch
But when I use

evmctl sign -u - --imahash new.sh

 Before reboot hash is well created



root@bt:~/Desktop# getfattr -m . -d new.sh # file: new.sh
security.evm=0sAwFGfvtRAABzverB5Wn60QEEAFuDBwwe/Dw4crcy8XYwVFgkKnIDwz4ZwHhwLs0Gf/QPrlJOM/gB1a7NhlCo9NArzbo0cfJxU2j28Amromvlmy6wtdbv3HbAuZbpbZ7JyGI9r3sQXarGV/z764G2Ic2myaUk1B9ADowDhKsQybNjuNVF7xNz2c30DSwLlLweP2gd
security.ima=0sAasqoo2HlztKurTEoLQjFIpsI9Fn


After reboot, hash is lost...

root@bt:~/Desktop# getfattr -m . -d new.sh
# file: new.sh
security.evm=0sApBPpCiVtujFqqeUkq5GIhuzX06b
security.ima=0sAasqoo2HlztKurTEoLQjFIpsI9Fn

 Every steps have been followed, creating RSA keys, loading them early at
boot in initramfs with keyctl.

Session Keyring
       -3 --alswrv      0 65534  keyring: _uid_ses.0977514165 --alswrv
     0 65534   \_ keyring: _uid.0572301790 --alswrv      0     0
\_ user: kmk-user126316032 --alswrv      0     0       \_ encrypted:
evm-key570886575 --alswrv      0     0       \_ keyring: _ima304346597
--alswrv      0     0       \_ keyring: _evm

However as soon as I reboot my OS when I try to read a signed and hashed
file I get the error "Permission Denied" Running dmesg tells me :

[ 5461.175996] type=1800 audit(1375262160.913:57): pid=1756 uid=0
auid=4294967295 ses=4294967295 op="appraise_data"
cause="**invalid-HMAC**" comm="sh" name="/root/Desktop/new.sh"
dev="sda1" ino=546526 res=0

Have you any idea why i get invalid HMAC ? The keys are loaded like the
tutorial says...

Maybe there is an issue known between new kernel (3.10.2) using modules IMA
& EVM verif functions to check integrity of file and the way on how I hash
security.evm xattr  with evmctl?


Thanks for your help

PS: I'm also looking, if it exists a good doc to explain how and when IMA
measurements are done.

Re: [Linux-ima-user] questions about the EVM extended attribute data structure

[Bo Z. <bob...@gm...>]

> > On Wed, Apr 3, 2013 at 8:45 PM, Mimi Zohar <zo...@li...> wrote:
>
<snip>

> The evm_ima_xattr_data structure represents the original ima hash/evm
> hmac xattr format.  For example, creating/copying a file will create a
> file with 'security.ima' containing a hash and 'security.evm' containing
> an hmac.
>
> # echo 'test digest' > /tmp/test.digest
> # getfattr -m ^security --e hex --dump /tmp/test.digest
> getfattr: Removing leading '/' from absolute path names
> # file: tmp/test.digest
> security.evm=0x0253d5ac6072468ae8520daa27c48f56ec3bcc3e36
> security.ima=0x0170d62ea5848cd8ee361664d5135e2fd7b25152dc
> security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a757365725f746d705f743a733000
>
> # getfattr -m ^security --dump /tmp/test.digest
> getfattr: Removing leading '/' from absolute path names
> # file: tmp/test.digest
> security.evm=0sAlPVrGByRoroUg2qJ8SPVuw7zD42
> security.ima=0sAXDWLqWEjNjuNhZk1RNeL9eyUVLc
> security.selinux="unconfined_u:object_r:user_tmp_t:s0"
>
> >
> > 5. in the user space, evmctl sets different formats with different parameters,
> > but the actual value passed to setxattr system call is a string (char *),
>
> From userspace, we can change the content of the xattrs from hash/hmac
> to signatures using evmctl.  The following examples uses the original
> ima/evm signature format, not the asymmetric signature format.
>
> # evmctl sign --imasig /tmp/test.digest
> # getfattr -m ^security --e hex --dump /tmp/test.digest
> getfattr: Removing leading '/' from absolute path names
> # file: tmp/test.digest
> security.evm=0x03017eac5d51000081eee6ac4f0f702401040058c45fce308a0100001990ac8cbf8f62a00ffdcec79a53312b0b0cfcb018d528b30289581ebce7c924d3e264cfb145f8cda6768268b12610618ce514f831fdadc67d2eb478ba59edab2ac3b06ee68323203fac0f505926a56b4b0e0f95fda7d55acce5c2741f3350eb49fb94e49ccf51ce9255ae62ca79b1f8fcfb8c0fc8a39d
> security.ima=0x03017eac5d51000081eee6ac4f0f7024010400849f9400b74d04ae1f323cd41c3a61824b0d6caa620b71c166f9ab90cfc9a89f03fd47cd28eca7ce80b028c4889bce74999542b894e214755884f0e0e101eac1d7b67ff270c3491320c93b0c2be385988221cd82d43aae14f3dedc7625a96adcbe62835ce85a3580fc80b2aa1f64f130f607998e3aa77eb83a3007efe07a14e4
> security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a757365725f746d705f743a733000

from your examples i guessed that the extended data being passed from
user space are not simple strings,
the first byte of 'security.ima' or 'security.evm' is in the set of
('0x01', '0x02', '0x03') that is corresponding with the enum in
[integrity.h]:

enum evm_ima_xattr_type {
    IMA_XATTR_DIGEST = 0x01,
    EVM_XATTR_HMAC,
    EVM_IMA_XATTR_DIGSIG,
};

digging evmctl's source code deeper, Dmitry handles the unsigned char
sig[1024] just like this:


unsigned char sig[1024] = "\x01";
unsigned char sig[1024] = "\x02";
unsigned char sig[1024] = "\x03";

so, my problems solved.

thank you.

> > 6. string vs. struct evm_ima_xattr_data, wouldn't this be a conflict ?
> > why don't we pass the ima or evm extended values from the user space
> > with a data structure like this?
> >
> > struct evm_ima_xattr_usersapce {
> >     int type;
> >     char digest[SHA1_DIGEST_SIZE];
> > } __attribute__((packed));
> >
> > just the same as kernel's.
>
> evmctl writes the hash/hmac/signature as a hex encoded string.
>
> From the setfattr man page:
>       -v value, --value=value
>            Specifies the new value of the extended attribute. There are  three
>            methods  available  for encoding the value.  If the given string is
>            enclosed in double quotes, the inner string is treated as text.  In
>            that  case, backslashes and double quotes have special meanings and
>            need to be escaped by a preceding backslash. Any control characters
>            can be encoded as a backslash followed by three digits as its ASCII
>            code in octal. If the  given  string  begins  with  0x  or  0X,  it
>            expresses  a hexadecimal number. If the given string begins with 0s
>            or 0S, base64 encoding is expected.  See also the --encoding option
>            of getfattr(1).
>
> From the getfattr man page:
>        -e en, --encoding=en
>            Encode values after  retrieving  them.   Valid  values  of  en  are
>            "text",  "hex",  and  "base64".  Values encoded as text strings are
>            enclosed in double quotes ("), while strings encoded as hexidecimal
>            and base64 are prefixed with 0x and 0s, respectively.
>
evmctl didn't use these two file utilities directly but system call
setxattr instead,
and its function parameters are (const char *path, const char *name,
const void *value, size_t size, int flags); ,
the value type is still a void pointer, so comparing to a tricky
string i think a structure like the following might be more
appropriate:

struct evm_ima_xattr_usersapce {
    int type;
    char digest[SHA1_DIGEST_SIZE];
} __attribute__((packed));

but so what, it just works ok, that's enough.

BR,
Bo Zhi

Re: [Linux-ima-user] questions about the EVM extended attribute data structure

[Mimi Z. <zo...@li...>]

On Thu, 2013-04-04 at 21:15 +0800, Bo Zhi wrote:
> On Wed, Apr 3, 2013 at 8:45 PM, Mimi Zohar <zo...@li...> wrote:

<snip>

> thank you, but you didn't solve my doubts yet, i think that is because
> i didn't express it clearly enough, sorry.
> let me describe my doubts again.
> 
> 1. the extended attributes associated with inodes are described as:
> struct xattr{
>     char *name;
>     void *value;
>     size_t value_len;
> };
> 
> 2.  the type of value in struct xattr is a void pointer, so it can be
> associated with any types of pointers.
> and in IMA, 'security.ima' and 'security.evm' are using the same data structure:
> 
> struct evm_ima_xattr_data {
>     u8 type;
>     u8 digest[SHA1_DIGEST_SIZE];
> } __attribute__((packed));
> 
> so, the void pointer is replaced with pointer of struct evm_ima_xattr_data.
> 
> 3. i know both 'security.evm' and 'security.ima' contains two formats
> extended attributes,
> so the type member is needed, and digest is just the real using data.
> 
> 4. when we are to set 'security.ima' or 'security.evm',
> we need set both evm_ima_xattr_data.type and evm_ima_xattr_data.value
> because of the definition.

The evm_ima_xattr_data structure represents the original ima hash/evm
hmac xattr format.  For example, creating/copying a file will create a
file with 'security.ima' containing a hash and 'security.evm' containing
an hmac.
 
# echo 'test digest' > /tmp/test.digest
# getfattr -m ^security --e hex --dump /tmp/test.digest
getfattr: Removing leading '/' from absolute path names
# file: tmp/test.digest
security.evm=0x0253d5ac6072468ae8520daa27c48f56ec3bcc3e36
security.ima=0x0170d62ea5848cd8ee361664d5135e2fd7b25152dc
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a757365725f746d705f743a733000

# getfattr -m ^security --dump /tmp/test.digest
getfattr: Removing leading '/' from absolute path names
# file: tmp/test.digest
security.evm=0sAlPVrGByRoroUg2qJ8SPVuw7zD42
security.ima=0sAXDWLqWEjNjuNhZk1RNeL9eyUVLc
security.selinux="unconfined_u:object_r:user_tmp_t:s0"

> 
> 5. in the user space, evmctl sets different formats with different parameters,
> but the actual value passed to setxattr system call is a string (char *),

>From userspace, we can change the content of the xattrs from hash/hmac
to signatures using evmctl.  The following examples uses the original
ima/evm signature format, not the asymmetric signature format.

# evmctl sign --imasig /tmp/test.digest
# getfattr -m ^security --e hex --dump /tmp/test.digest
getfattr: Removing leading '/' from absolute path names
# file: tmp/test.digest
security.evm=0x03017eac5d51000081eee6ac4f0f702401040058c45fce308a0100001990ac8cbf8f62a00ffdcec79a53312b0b0cfcb018d528b30289581ebce7c924d3e264cfb145f8cda6768268b12610618ce514f831fdadc67d2eb478ba59edab2ac3b06ee68323203fac0f505926a56b4b0e0f95fda7d55acce5c2741f3350eb49fb94e49ccf51ce9255ae62ca79b1f8fcfb8c0fc8a39d
security.ima=0x03017eac5d51000081eee6ac4f0f7024010400849f9400b74d04ae1f323cd41c3a61824b0d6caa620b71c166f9ab90cfc9a89f03fd47cd28eca7ce80b028c4889bce74999542b894e214755884f0e0e101eac1d7b67ff270c3491320c93b0c2be385988221cd82d43aae14f3dedc7625a96adcbe62835ce85a3580fc80b2aa1f64f130f607998e3aa77eb83a3007efe07a14e4
security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a757365725f746d705f743a733000

> 6. string vs. struct evm_ima_xattr_data, wouldn't this be a conflict ?
> why don't we pass the ima or evm extended values from the user space
> with a data structure like this?
> 
> struct evm_ima_xattr_usersapce {
>     int type;
>     char digest[SHA1_DIGEST_SIZE];
> } __attribute__((packed));
> 
> just the same as kernel's.

evmctl writes the hash/hmac/signature as a hex encoded string.

>From the setfattr man page:
      -v value, --value=value
           Specifies the new value of the extended attribute. There are  three
           methods  available  for encoding the value.  If the given string is
           enclosed in double quotes, the inner string is treated as text.  In
           that  case, backslashes and double quotes have special meanings and
           need to be escaped by a preceding backslash. Any control characters
           can be encoded as a backslash followed by three digits as its ASCII
           code in octal. If the  given  string  begins  with  0x  or  0X,  it
           expresses  a hexadecimal number. If the given string begins with 0s
           or 0S, base64 encoding is expected.  See also the --encoding option
           of getfattr(1).

>From the getfattr man page:
       -e en, --encoding=en
           Encode values after  retrieving  them.   Valid  values  of  en  are
           "text",  "hex",  and  "base64".  Values encoded as text strings are
           enclosed in double quotes ("), while strings encoded as hexidecimal
           and base64 are prefixed with 0x and 0s, respectively.


> thank you, hope i didn't say anything wrong, did i ?

Absolutely not!

Mimi

Re: [Linux-ima-user] questions about the EVM extended attribute data structure

[Bo Z. <bob...@gm...>]

On Wed, Apr 3, 2013 at 8:45 PM, Mimi Zohar <zo...@li...> wrote:
>
> On Tue, 2013-04-02 at 03:19 +0800, Bo Zhi wrote:
> > hi, all
> >
> > I have some questions about the EVM extended attribute data structure.
> >
> > first, why is the EVM xattr data structure different between kernel
> > space and user space ?
> >
> > here is the definition of EVM xattr data structure in kernel (3.8.0):
> >
> >         struct evm_ima_xattr_data {
> >             u8 type;
> >             u8 digest[SHA1_DIGEST_SIZE];
> >         }  __attribute__((packed));
> >
> > and the init and update operations in kernel (3.8.0) are all operated
> > with "struct evm_ima_xattr_data", e.g.
> >
> > [in evm_main.c]
> >         int evm_inode_init_security(struct inode *inode,
> >          const struct xattr *lsm_xattr,
> >          struct xattr *evm_xattr)
> >         {
> >         struct evm_ima_xattr_data *xattr_data;
> >         int rc;
> >                 ...
> >         xattr_data->type = EVM_XATTR_HMAC;
> >         rc = evm_init_hmac(inode, lsm_xattr, xattr_data->digest);
> >         if (rc < 0)
> >         goto out;
> >
> >
> >         evm_xattr->value = xattr_data;
> >         evm_xattr->value_len = sizeof(*xattr_data);
> >         evm_xattr->name = kstrdup(XATTR_EVM_SUFFIX, GFP_NOFS);
> >         return 0;
> >         out:
> >         kfree(xattr_data);
> >         return rc;
> >         }
> >
> >
> > [in evm_crypto.c]
> >         int evm_update_evmxattr(struct dentry *dentry, const char
> >         *xattr_name,
> >         const char *xattr_value, size_t xattr_value_len)
> >         {
> >         struct inode *inode = dentry->d_inode;
> >         struct evm_ima_xattr_data xattr_data;
> >         int rc = 0;
> >
> >
> >         rc = evm_calc_hmac(dentry, xattr_name, xattr_value,
> >            xattr_value_len, xattr_data.digest);
> >         if (rc == 0) {
> >         xattr_data.type = EVM_XATTR_HMAC;
> >         rc = __vfs_setxattr_noperm(dentry, XATTR_NAME_EVM,
> >            &xattr_data,
> >            sizeof(xattr_data), 0);
> >         } else if (rc == -ENODATA && inode->i_op->removexattr) {
> >         rc = inode->i_op->removexattr(dentry, XATTR_NAME_EVM);
> >         }
> >         return rc;
> >         }
> >
> >
> >
> >
> > while in the ima-evm-utils(evmctl),  security.evm is signed with
> > "unsigned char sig[1024]"
> >
> >
> >         static int sign_evm(const char *file, const char *key)
> >         {
> >             unsigned char hash[20];
> >             unsigned char sig[1024] = "\x03";
> >             ...
> >                 err = setxattr(file, "security.evm", sig, len + 1, 0);
> >                 if (err < 0) {
> >                     log_err("setxattr failed: %s\n", file);
> >                     return err;
> >                 }
> >             return 0;
> >         }
> >
> > I am confused here, can anybody help me ?
> >
> > second, I have already run the IMA module and ima-evm-utils on Gentoo
> > with these docs:
> >
> > [1]
> > http://www.gentoo.org/proj/en/hardened/integrity/docs/ima-guide.xml
> > [2]
> > http://www.gentoo.org/proj/en/hardened/integrity/docs/evm-guide.xml
> >
> >
> > and get security.ima and security.evm like this:
> >
> >
> >         tcel keys # getfattr -m . -d ~/pgydyd
> >         # file: root/pgydyd
> >         security.evm=0sAwFKz
> >         +1QAAA9Yz7H6RrISQEEAC8rEMhvs9q5HkwTU1EJOCdCTz0KLyhR1knpH/yT
> >         W0EPa241Z+d4gSvX2cQadcKlpNAFw+f5LWHQrNVyXAERY3
> >         +GGA3LPaEucGeXv6UseKuhblFD57S
> >         WO901IM4woC2zRcq55dD0rkNYxEz/vKmmYuVjRnh9RX6bQWH68/yvCwSh
> >         security.ima=0sAYP1pcNZ89yDF1GSQOMvH1H2i8BR
> >
> >
> > the format of the hash or sign result is totally different with [1]'s:
> >
> >
> >         ~# getfattr -m . -d /boot/grub/grub.conf
> >         # file: grub.conf
> >         security.selinux="root:object_r:boot_t"
> >         security.ima="76a0d787be14d84dfe3cf3930ac3da38bb389464"
> >
> >
> > I don't believe this is a programming mistake, maybe I did something
> > wrong, or it is related with the first question.
> >
> >
> > thanks in advance :)
>
> 'security.evm' contains either an HMAC or a digital signature, of which
> there are two formats - original, asymmetric. 'security.ima' contains
> either a hash or a digital signature.  Based on the evmctl arguments,
> determines both the 'security.evm' and 'security.ima' xattr contents.
>
> evm_verify_hmac() verifies the HMAC or calls integrity_digsig_verify(),
> which in turn calls either digsig_verify() or asymmetric_verify(), to
> verify the digital signature.
>
> Try using the getfattr '--e hex' option to output the binary data in
> hex.
>
hi, Mimi,

thank you, but you didn't solve my doubts yet, i think that is because
i didn't express it clearly enough, sorry.
let me describe my doubts again.

1. the extended attributes associated with inodes are described as:
struct xattr{
    char *name;
    void *value;
    size_t value_len;
};

2.  the type of value in struct xattr is a void pointer, so it can be
associated with any types of pointers.
and in IMA, 'security.ima' and 'security.evm' are using the same data structure:

struct evm_ima_xattr_data {
    u8 type;
    u8 digest[SHA1_DIGEST_SIZE];
} __attribute__((packed));

so, the void pointer is replaced with pointer of struct evm_ima_xattr_data.

3. i know both 'security.evm' and 'security.ima' contains two formats
extended attributes,
so the type member is needed, and digest is just the real using data.

4. when we are to set 'security.ima' or 'security.evm',
we need set both evm_ima_xattr_data.type and evm_ima_xattr_data.value
because of the definition.
and the kernel code in "integrity" is just doing like this.(i know you
are very familiar with it :) )

5. in the user space, evmctl sets different formats with different parameters,
but the actual value passed to setxattr system call is a string (char *),

6. string vs. struct evm_ima_xattr_data, wouldn't this be a conflict ?
why don't we pass the ima or evm extended values from the user space
with a data structure like this?

struct evm_ima_xattr_usersapce {
    int type;
    char digest[SHA1_DIGEST_SIZE];
} __attribute__((packed));

just the same as kernel's.


thank you, hope i didn't say anything wrong, did i ?

best regards,

Bo Zhi

> thanks,
>
> Mimi
>
> >
> > btw, i am a student and now i am trying to develop another security
> > module which is related with IMA,
> > i have read the source code of "integrity" about 4 or 5 days.
> >
> >
> > Best Regards,
> >
> > Zhi Bo
>
>

Re: [Linux-ima-user] questions about the EVM extended attribute data structure

[Mimi Z. <zo...@li...>]

On Tue, 2013-04-02 at 03:19 +0800, Bo Zhi wrote:
> hi, all
> 
> I have some questions about the EVM extended attribute data structure.
> 
> first, why is the EVM xattr data structure different between kernel
> space and user space ?
> 
> here is the definition of EVM xattr data structure in kernel (3.8.0):
> 
>         struct evm_ima_xattr_data {
>             u8 type;
>             u8 digest[SHA1_DIGEST_SIZE];
>         }  __attribute__((packed));
> 
> and the init and update operations in kernel (3.8.0) are all operated
> with "struct evm_ima_xattr_data", e.g.
> 
> [in evm_main.c]
>         int evm_inode_init_security(struct inode *inode,
>          const struct xattr *lsm_xattr,
>          struct xattr *evm_xattr)
>         {
>         struct evm_ima_xattr_data *xattr_data;
>         int rc;
>                 ...
>         xattr_data->type = EVM_XATTR_HMAC;
>         rc = evm_init_hmac(inode, lsm_xattr, xattr_data->digest);
>         if (rc < 0)
>         goto out;
>         
>         
>         evm_xattr->value = xattr_data;
>         evm_xattr->value_len = sizeof(*xattr_data);
>         evm_xattr->name = kstrdup(XATTR_EVM_SUFFIX, GFP_NOFS);
>         return 0;
>         out:
>         kfree(xattr_data);
>         return rc;
>         }
> 
> 
> [in evm_crypto.c]
>         int evm_update_evmxattr(struct dentry *dentry, const char
>         *xattr_name,
>         const char *xattr_value, size_t xattr_value_len)
>         {
>         struct inode *inode = dentry->d_inode;
>         struct evm_ima_xattr_data xattr_data;
>         int rc = 0;
>         
>         
>         rc = evm_calc_hmac(dentry, xattr_name, xattr_value,
>            xattr_value_len, xattr_data.digest);
>         if (rc == 0) {
>         xattr_data.type = EVM_XATTR_HMAC;
>         rc = __vfs_setxattr_noperm(dentry, XATTR_NAME_EVM,
>            &xattr_data,
>            sizeof(xattr_data), 0);
>         } else if (rc == -ENODATA && inode->i_op->removexattr) {
>         rc = inode->i_op->removexattr(dentry, XATTR_NAME_EVM);
>         }
>         return rc;
>         }
>         
>         
>         
>         
> while in the ima-evm-utils(evmctl),  security.evm is signed with
> "unsigned char sig[1024]"
> 
> 
>         static int sign_evm(const char *file, const char *key)
>         {
>             unsigned char hash[20];
>             unsigned char sig[1024] = "\x03";
>             ...
>                 err = setxattr(file, "security.evm", sig, len + 1, 0);
>                 if (err < 0) {
>                     log_err("setxattr failed: %s\n", file);
>                     return err;
>                 }
>             return 0;
>         }
> 
> I am confused here, can anybody help me ?
> 
> second, I have already run the IMA module and ima-evm-utils on Gentoo
> with these docs:
> 
> [1]
> http://www.gentoo.org/proj/en/hardened/integrity/docs/ima-guide.xml
> [2]
> http://www.gentoo.org/proj/en/hardened/integrity/docs/evm-guide.xml 
> 
> 
> and get security.ima and security.evm like this:
> 
> 
>         tcel keys # getfattr -m . -d ~/pgydyd 
>         # file: root/pgydyd
>         security.evm=0sAwFKz
>         +1QAAA9Yz7H6RrISQEEAC8rEMhvs9q5HkwTU1EJOCdCTz0KLyhR1knpH/yT
>         W0EPa241Z+d4gSvX2cQadcKlpNAFw+f5LWHQrNVyXAERY3
>         +GGA3LPaEucGeXv6UseKuhblFD57S
>         WO901IM4woC2zRcq55dD0rkNYxEz/vKmmYuVjRnh9RX6bQWH68/yvCwSh
>         security.ima=0sAYP1pcNZ89yDF1GSQOMvH1H2i8BR
>         
>         
> the format of the hash or sign result is totally different with [1]'s:
> 
> 
>         ~# getfattr -m . -d /boot/grub/grub.conf 
>         # file: grub.conf 
>         security.selinux="root:object_r:boot_t" 
>         security.ima="76a0d787be14d84dfe3cf3930ac3da38bb389464"
> 
> 
> I don't believe this is a programming mistake, maybe I did something
> wrong, or it is related with the first question.
> 
> 
> thanks in advance :)

'security.evm' contains either an HMAC or a digital signature, of which
there are two formats - original, asymmetric. 'security.ima' contains
either a hash or a digital signature.  Based on the evmctl arguments,
determines both the 'security.evm' and 'security.ima' xattr contents.

evm_verify_hmac() verifies the HMAC or calls integrity_digsig_verify(),
which in turn calls either digsig_verify() or asymmetric_verify(), to
verify the digital signature.

Try using the getfattr '--e hex' option to output the binary data in
hex.

thanks,

Mimi

> 
> btw, i am a student and now i am trying to develop another security
> module which is related with IMA,
> i have read the source code of "integrity" about 4 or 5 days.
> 
> 
> Best Regards,
> 
> Zhi Bo

[Linux-ima-user] questions about the EVM extended attribute data structure

[Bo Z. <bob...@gm...>]

hi, all

I have some questions about the EVM extended attribute data structure.

first, why is the EVM xattr data structure different between kernel space
and user space ?

here is the definition of EVM xattr data structure in kernel (3.8.0):

struct evm_ima_xattr_data {
    u8 type;
    u8 digest[SHA1_DIGEST_SIZE];
}  __attribute__((packed));


and the init and update operations in kernel (3.8.0) are all operated with
"struct evm_ima_xattr_data", e.g.

[in evm_main.c]

int evm_inode_init_security(struct inode *inode,
 const struct xattr *lsm_xattr,
  struct xattr *evm_xattr)
{
struct evm_ima_xattr_data *xattr_data;
int rc;
        ...
xattr_data->type = EVM_XATTR_HMAC;
rc = evm_init_hmac(inode, lsm_xattr, xattr_data->digest);
 if (rc < 0)
goto out;

evm_xattr->value = xattr_data;
 evm_xattr->value_len = sizeof(*xattr_data);
evm_xattr->name = kstrdup(XATTR_EVM_SUFFIX, GFP_NOFS);
 return 0;
out:
kfree(xattr_data);
return rc;
}


[in evm_crypto.c]

int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
const char *xattr_value, size_t xattr_value_len)
{
struct inode *inode = dentry->d_inode;
struct evm_ima_xattr_data xattr_data;
int rc = 0;

rc = evm_calc_hmac(dentry, xattr_name, xattr_value,
   xattr_value_len, xattr_data.digest);
 if (rc == 0) {
xattr_data.type = EVM_XATTR_HMAC;
rc = __vfs_setxattr_noperm(dentry, XATTR_NAME_EVM,
    &xattr_data,
   sizeof(xattr_data), 0);
} else if (rc == -ENODATA && inode->i_op->removexattr) {
 rc = inode->i_op->removexattr(dentry, XATTR_NAME_EVM);
}
return rc;
}


while in the ima-evm-utils(evmctl),  security.evm is signed with "unsigned
char sig[1024]"


static int sign_evm(const char *file, const char *key)
{
    unsigned char hash[20];
    unsigned char sig[1024] = "\x03";
    ...
        err = setxattr(file, "security.evm", sig, len + 1, 0);
        if (err < 0) {
            log_err("setxattr failed: %s\n", file);
            return err;
        }
    return 0;
}


I am confused here, can anybody help me ?

second, I have already run the IMA module and ima-evm-utils on Gentoo with
these docs:

[1] http://www.gentoo.org/proj/en/hardened/integrity/docs/ima-guide.xml
[2] http://www.gentoo.org/proj/en/hardened/integrity/docs/evm-guide.xml

and get security.ima and security.evm like this:

tcel keys # getfattr -m . -d ~/pgydyd
# file: root/pgydyd
security.evm=0sAwFKz+1QAAA9Yz7H6RrISQEEAC8rEMhvs9q5HkwTU1EJOCdCTz0KLyhR1knpH/yT
W0EPa241Z+d4gSvX2cQadcKlpNAFw+f5LWHQrNVyXAERY3+GGA3LPaEucGeXv6UseKuhblFD57S
WO901IM4woC2zRcq55dD0rkNYxEz/vKmmYuVjRnh9RX6bQWH68/yvCwSh
security.ima=0sAYP1pcNZ89yDF1GSQOMvH1H2i8BR

the format of the hash or sign result is totally different with [1]'s:

~# getfattr -m . -d /boot/grub/grub.conf
# file: grub.conf
security.selinux="root:object_r:boot_t"
security.ima="76a0d787be14d84dfe3cf3930ac3da38bb389464"


I don't believe this is a programming mistake, maybe I did something wrong,
or it is related with the first question.

thanks in advance :)

btw, i am a student and now i am trying to develop another security module
which is related with IMA,
i have read the source code of "integrity" about 4 or 5 days.

Best Regards,

Zhi Bo

Re: [Linux-ima-user] [Linux-ima-devel] Query about evmctl and hash algo

[Roberto S. <rob...@po...>]

Il 3/13/2013 10:16 PM, Mimi Zohar ha scritto:
> On Wed, 2013-03-13 at 21:42 +0100, Roberto Sassu wrote:
>> Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
>>> On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
>>>> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> I used evmctl to sign an executable. I used an x.509 cert. I generated
>>>>> cert and specified to use -sha256 algorithm.
>>>>>
>>>>> But I noticed that evmctl ignores x.509 values and by default calculates
>>>>> sha1 hash.
>>>>>
>>>>> I thought we should honor x.509 certificate and use the hashing algorithm
>>>>> as specified in the cert. What do you think?
>>>>>
>>>>
>>>> Or may be I have misunderstood it and x.509 does not impose the type
>>>> of hash algorithm that should be used for signing. And user is free to
>>>> use any hash algorithm.
>>>
>>> Vivek, we definitely want to be able to collect, store, and appraise
>>> files based on the signature hash algorithm.  For now, the kernel only
>>> supports sha1.  Dmitry has some kernel patches in his
>>> linux-digsig/#working branch, which are not yet quite ready to be posted
>>> or upstreamed.
>>>
>>> Before being able to support hashes larger than md5/sha1, we also need
>>> to modify the existing 'ima' template.  Otherwise we would need to hash
>>> the file twice - once for the measurement list and again based on the
>>> signature.  I've pushed out some patches yesterday, which also are not
>>> quite ready for review, to the "next-multiple-template" branch.  These
>>> patches are based on the 'template' patches written 3+ years ago, but
>>> were never upstreamed.  Below is the patch description from the first
>>> patch.
>>>
>>>       The original 'ima' template data includes just the file hash and
>>>       filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
>>>       The filename is a null terminated string, limited to 255 characters.
>>>       To overcome these limitations, and provide additional file metadata,
>>>       this patch set introduces multiple templates of variable length sizes.
>>>       Future patches will address TPM v2.0 changes.
>>>
>>>       This first patch adds the template data length to the
>>>       binary_runtime_measurements list.  As new templates are defined,
>>>       userspace will continue being able to verify the measurement list
>>>       against the PCR value, yet skip unknown templates.
>>>
>>>       For the patches to be bisect safe and not break userspace, defer
>>>       adding the ability to change the template, until the 'ima-ng' template
>>>       definition is complete.
>>>
>>> The patches to support larger hashes, will be included prior, to the
>>> last patch in this patch set, which changes the default 'ima' template
>>> to 'ima-ng' template and adds a boot command line option for backwards
>>> compatibility.  For a better understanding of what needs to be done,
>>> please refer to the individual patch descriptions.
>>>
>>
>> Hi Mimi, Vivek
>>
>> I'm following this mailing list and I noticed that there is some
>> activity about the IMA templates topic.
>>
>> I'm currently working in this area and I produced some patches that
>> introduce this functionality. They are completely different from
>> those that were developed some years ago. For example, now, in my
>> implementation, it is possible to define a template as a set of fields
>> separated by '|'. Also, there are template names that are associated
>> to a specific set of fields.
>>
>> Each field is defined by two functions: init() to populate data from
>> arguments passed to this function and show() to display that data in
>> ascii or in binary format so that IMA should not be aware of the format
>> but it only has to store the data.
>>
>> I will deliver these patches shortly.
>
> It sounds like a really interesting solution, that scales a lot better
> than what we originally had.  My concern is userspace (eg. trousers,
> openpts, etc) being able to parse this dynamic, variable measurement
> list definition.  I'm looking forward to seeing the patches!
>

Yes, that could be a problem. However, I think this solution eases the
task of adding support for multiple templates in userspace programs
as these applications should only implement a parser for each field
identifier and then, they are capable of inspecting a generic
measurement by retrieving the format contained in the measurement
itself.

Roberto Sassu


> thanks,
>
> Mimi
>

Re: [Linux-ima-user] [Linux-ima-devel] Query about evmctl and hash algo

[Mimi Z. <zo...@li...>]

On Wed, 2013-03-13 at 21:42 +0100, Roberto Sassu wrote:
> Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
> > On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
> >> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
> >>> Hi Dmitry,
> >>>
> >>> I used evmctl to sign an executable. I used an x.509 cert. I generated
> >>> cert and specified to use -sha256 algorithm.
> >>>
> >>> But I noticed that evmctl ignores x.509 values and by default calculates
> >>> sha1 hash.
> >>>
> >>> I thought we should honor x.509 certificate and use the hashing algorithm
> >>> as specified in the cert. What do you think?
> >>>
> >>
> >> Or may be I have misunderstood it and x.509 does not impose the type
> >> of hash algorithm that should be used for signing. And user is free to
> >> use any hash algorithm.
> >
> > Vivek, we definitely want to be able to collect, store, and appraise
> > files based on the signature hash algorithm.  For now, the kernel only
> > supports sha1.  Dmitry has some kernel patches in his
> > linux-digsig/#working branch, which are not yet quite ready to be posted
> > or upstreamed.
> >
> > Before being able to support hashes larger than md5/sha1, we also need
> > to modify the existing 'ima' template.  Otherwise we would need to hash
> > the file twice - once for the measurement list and again based on the
> > signature.  I've pushed out some patches yesterday, which also are not
> > quite ready for review, to the "next-multiple-template" branch.  These
> > patches are based on the 'template' patches written 3+ years ago, but
> > were never upstreamed.  Below is the patch description from the first
> > patch.
> >
> >      The original 'ima' template data includes just the file hash and
> >      filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
> >      The filename is a null terminated string, limited to 255 characters.
> >      To overcome these limitations, and provide additional file metadata,
> >      this patch set introduces multiple templates of variable length sizes.
> >      Future patches will address TPM v2.0 changes.
> >
> >      This first patch adds the template data length to the
> >      binary_runtime_measurements list.  As new templates are defined,
> >      userspace will continue being able to verify the measurement list
> >      against the PCR value, yet skip unknown templates.
> >
> >      For the patches to be bisect safe and not break userspace, defer
> >      adding the ability to change the template, until the 'ima-ng' template
> >      definition is complete.
> >
> > The patches to support larger hashes, will be included prior, to the
> > last patch in this patch set, which changes the default 'ima' template
> > to 'ima-ng' template and adds a boot command line option for backwards
> > compatibility.  For a better understanding of what needs to be done,
> > please refer to the individual patch descriptions.
> >
> 
> Hi Mimi, Vivek
> 
> I'm following this mailing list and I noticed that there is some
> activity about the IMA templates topic.
> 
> I'm currently working in this area and I produced some patches that
> introduce this functionality. They are completely different from
> those that were developed some years ago. For example, now, in my
> implementation, it is possible to define a template as a set of fields
> separated by '|'. Also, there are template names that are associated
> to a specific set of fields.
> 
> Each field is defined by two functions: init() to populate data from
> arguments passed to this function and show() to display that data in
> ascii or in binary format so that IMA should not be aware of the format
> but it only has to store the data.
> 
> I will deliver these patches shortly.

It sounds like a really interesting solution, that scales a lot better
than what we originally had.  My concern is userspace (eg. trousers,
openpts, etc) being able to parse this dynamic, variable measurement
list definition.  I'm looking forward to seeing the patches!

thanks,

Mimi

Re: [Linux-ima-user] [Linux-ima-devel] Query about evmctl and hash algo

[Roberto S. <rob...@po...>]

Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
> On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
>> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
>>> Hi Dmitry,
>>>
>>> I used evmctl to sign an executable. I used an x.509 cert. I generated
>>> cert and specified to use -sha256 algorithm.
>>>
>>> But I noticed that evmctl ignores x.509 values and by default calculates
>>> sha1 hash.
>>>
>>> I thought we should honor x.509 certificate and use the hashing algorithm
>>> as specified in the cert. What do you think?
>>>
>>
>> Or may be I have misunderstood it and x.509 does not impose the type
>> of hash algorithm that should be used for signing. And user is free to
>> use any hash algorithm.
>
> Vivek, we definitely want to be able to collect, store, and appraise
> files based on the signature hash algorithm.  For now, the kernel only
> supports sha1.  Dmitry has some kernel patches in his
> linux-digsig/#working branch, which are not yet quite ready to be posted
> or upstreamed.
>
> Before being able to support hashes larger than md5/sha1, we also need
> to modify the existing 'ima' template.  Otherwise we would need to hash
> the file twice - once for the measurement list and again based on the
> signature.  I've pushed out some patches yesterday, which also are not
> quite ready for review, to the "next-multiple-template" branch.  These
> patches are based on the 'template' patches written 3+ years ago, but
> were never upstreamed.  Below is the patch description from the first
> patch.
>
>      The original 'ima' template data includes just the file hash and
>      filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
>      The filename is a null terminated string, limited to 255 characters.
>      To overcome these limitations, and provide additional file metadata,
>      this patch set introduces multiple templates of variable length sizes.
>      Future patches will address TPM v2.0 changes.
>
>      This first patch adds the template data length to the
>      binary_runtime_measurements list.  As new templates are defined,
>      userspace will continue being able to verify the measurement list
>      against the PCR value, yet skip unknown templates.
>
>      For the patches to be bisect safe and not break userspace, defer
>      adding the ability to change the template, until the 'ima-ng' template
>      definition is complete.
>
> The patches to support larger hashes, will be included prior, to the
> last patch in this patch set, which changes the default 'ima' template
> to 'ima-ng' template and adds a boot command line option for backwards
> compatibility.  For a better understanding of what needs to be done,
> please refer to the individual patch descriptions.
>

Hi Mimi, Vivek

I'm following this mailing list and I noticed that there is some
activity about the IMA templates topic.

I'm currently working in this area and I produced some patches that
introduce this functionality. They are completely different from
those that were developed some years ago. For example, now, in my
implementation, it is possible to define a template as a set of fields
separated by '|'. Also, there are template names that are associated
to a specific set of fields.

Each field is defined by two functions: init() to populate data from
arguments passed to this function and show() to display that data in
ascii or in binary format so that IMA should not be aware of the format
but it only has to store the data.

I will deliver these patches shortly.

Regards

Roberto Sassu


> thanks,
>
> Mimih
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Linux-ima-user mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ima-user
>

Re: [Linux-ima-user] [Linux-ima-devel] Query about evmctl and hash algo

[Mimi Z. <zo...@li...>]

On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
> > Hi Dmitry,
> > 
> > I used evmctl to sign an executable. I used an x.509 cert. I generated
> > cert and specified to use -sha256 algorithm.
> > 
> > But I noticed that evmctl ignores x.509 values and by default calculates
> > sha1 hash.
> > 
> > I thought we should honor x.509 certificate and use the hashing algorithm
> > as specified in the cert. What do you think?
> > 
> 
> Or may be I have misunderstood it and x.509 does not impose the type
> of hash algorithm that should be used for signing. And user is free to 
> use any hash algorithm.

Vivek, we definitely want to be able to collect, store, and appraise
files based on the signature hash algorithm.  For now, the kernel only
supports sha1.  Dmitry has some kernel patches in his
linux-digsig/#working branch, which are not yet quite ready to be posted
or upstreamed.

Before being able to support hashes larger than md5/sha1, we also need
to modify the existing 'ima' template.  Otherwise we would need to hash
the file twice - once for the measurement list and again based on the
signature.  I've pushed out some patches yesterday, which also are not
quite ready for review, to the "next-multiple-template" branch.  These
patches are based on the 'template' patches written 3+ years ago, but
were never upstreamed.  Below is the patch description from the first
patch.

    The original 'ima' template data includes just the file hash and
    filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
    The filename is a null terminated string, limited to 255 characters.
    To overcome these limitations, and provide additional file metadata,
    this patch set introduces multiple templates of variable length sizes.
    Future patches will address TPM v2.0 changes.
    
    This first patch adds the template data length to the
    binary_runtime_measurements list.  As new templates are defined,
    userspace will continue being able to verify the measurement list
    against the PCR value, yet skip unknown templates.
    
    For the patches to be bisect safe and not break userspace, defer
    adding the ability to change the template, until the 'ima-ng' template
    definition is complete.

The patches to support larger hashes, will be included prior, to the
last patch in this patch set, which changes the default 'ima' template
to 'ima-ng' template and adds a boot command line option for backwards
compatibility.  For a better understanding of what needs to be done,
please refer to the individual patch descriptions.

thanks,

Mimih

Re: [Linux-ima-user] ima_collect_measurement() changes

[Peter M. <pm...@go...>]

On Mon, Feb 25, 2013 at 8:15 AM, Mimi Zohar <zo...@li...> wrote:
> On Mon, 2013-02-25 at 07:43 -0800, Peter Moody wrote:
>> No issues from me. Do you have any pointers on how something like this
>> would be configured?
>
> I don't think it would be a configuration issue so much.  Without
> IMA-appraisal enabled, collection would remain the same as it today,
> using a single system defined hash algorithm.  For those systems with
> IMA-appraisal enabled, the file hash/signature in 'security.ima' would
> contain the hash algorithm.  Prior to collecting, or as part of
> collecting, we would need to pre-read the extended attribute to know
> which hash algorithm to use.

Hey Mimi,

thanks for the explanation. We're not using appraisal at the moment so
this change wouldn't affect us.

Cheers,
peter


-- 
[ Peter Moody | Security Engineer | Google ]

Re: [Linux-ima-user] ima_collect_measurement() changes

[Mimi Z. <zo...@li...>]

On Mon, 2013-02-25 at 07:43 -0800, Peter Moody wrote:
> No issues from me. Do you have any pointers on how something like this
> would be configured?

I don't think it would be a configuration issue so much.  Without
IMA-appraisal enabled, collection would remain the same as it today,
using a single system defined hash algorithm.  For those systems with
IMA-appraisal enabled, the file hash/signature in 'security.ima' would
contain the hash algorithm.  Prior to collecting, or as part of
collecting, we would need to pre-read the extended attribute to know
which hash algorithm to use.

Dmitry has some initial patches in his linux-digsig-working tree:

d0b7a6a ima: read and use signature hash algorithm
b16e2c9 ima: pass hash algo info to collecting functions
2868435 ima: remove xattr value from iint object

These changes would affect the measurement lists.  Some of the template
patches could be resurrected to address these issues:

ima: add template length to binary runtime measurement
ima: add support for additional template hash algorithm
ima: define ima nglong template
ima: add LSM labels to the ima nglong template

thanks,

Mimi

Re: [Linux-ima-user] ima_collect_measurement() changes

[Peter M. <pm...@go...>]

No issues from me. Do you have any pointers on how something like this
would be configured?

On Mon, Feb 25, 2013 at 6:12 AM, Mimi Zohar <zo...@li...> wrote:
> File measurements today are all sha1 (or md5).  When template support was
> discussed years ago, we spoke about supporting additional hash algorithms,
> but that was at the system level - all files would be similarly hashed.
> With the asymmetric key support, the hash algorithm used to sign files could
> be on a per package or even file basis.  Before making changes to
> ima_collect_measurement(), are there any objections to this sort of change?
>
> thanks,
>
> Mimi



-- 
[ Peter Moody | Security Engineer | Google ]

[Linux-ima-user] ima_collect_measurement() changes

[Mimi Z. <zo...@li...>]

File measurements today are all sha1 (or md5).  When template support
was discussed years ago, we spoke about supporting additional hash
algorithms, but that was at the system level - all files would be
similarly hashed.   With the asymmetric key support, the hash algorithm
used to sign files could be on a per package or even file basis.  Before
making changes to  ima_collect_measurement(), are there any objections
to this sort of change?

thanks,

Mimi

Re: [Linux-ima-user] IMA appraisal does not allow changing mode of files

[Mimi Z. <zo...@li...>]

On Thu, 2013-02-21 at 19:51 +0100, Sven Vermeulen wrote:
> On Tue, Feb 19, 2013 at 04:36:47PM -0500, Mimi Zohar wrote:
> > > It is just that changing the mode (chmod 0644 utmp) or even SELinux context
> > > fails:
> > > 
> > > #v+
> > > test run # chcon -t var_run_t utmp
> > > chcon: failed to change context of 'utmp' to 'system_u:object_r:var_run_t':
> > > Operation not permitted
> > > #v-
> > > 
> > > I do not get anything in dmesg, audit.log or kern.log. Someone any idea?
> > 
> > Before modifying an EVM protected extended attribute or anything
> > included in the HMAC calculation, the existing 'security.evm' is
> > verified.  Commit 74de668 "evm: add file system uuid to EVM hmac"
> > changed the HMAC calculation method to include the UUID.  If your system
> > is already 'security.evm' labeled, for backwards compatibility set
> > CONFIG_EVM_HMAC_VERSION to 1.
> 
> The problem is also there with a new file (so there is no security.evm xattr
> available yet):

The 'security.selinux' is created as soon as you open the file, which
causes 'security.evm' to be written as well.

> #v+
> test test # id
> uid=0(root) gid=0(root)
> groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video)
> context=root:sysadm_r:sysadm_t
> 
> test test # pwd
> /run/test
> 
> test test # ls -la
> total 0
> drwxr-xr-x. 2 root root  40 Feb 21 19:47 .
> drwxr-xr-x. 7 root root 160 Feb 21 19:47 ..
> 
> test test # touch foo
> 
> test test # getfattr -m . -d foo
> # file: foo
> security.evm=0sAoOwy0XjhHWculydtncU+R2gRihz
> security.selinux="root:object_r:var_run_t"

Before changing the mode, you should be able to open the empty file.
Not being able to open the file, would explain why you can't change the
mode.

> test test # chmod 0600 foo
> chmod: changing permissions of 'foo': Operation not permitted
> #v-

> I can also confirm it is indeed EVM-related: running with IMA in enforcing
> but EVM=fix doesn't show the behavior.

Something is modifying the file's metadata without 'security.evm' being
updated.

It took me a while to figure out that the posix xattr acls are 'system'
prefixed, which normally would not affect security.evm.  An interesting
side affect of writing posix xattr acls is their modifying of the
i_mode, which is included in security.evm.

Your example works on my system, not that it makes a difference.

thanks,

Mimi

Re: [Linux-ima-user] IMA appraisal does not allow changing mode of files

[Sven V. <sve...@si...>]

On Tue, Feb 19, 2013 at 04:36:47PM -0500, Mimi Zohar wrote:
> > It is just that changing the mode (chmod 0644 utmp) or even SELinux context
> > fails:
> > 
> > #v+
> > test run # chcon -t var_run_t utmp
> > chcon: failed to change context of 'utmp' to 'system_u:object_r:var_run_t':
> > Operation not permitted
> > #v-
> > 
> > I do not get anything in dmesg, audit.log or kern.log. Someone any idea?
> 
> Before modifying an EVM protected extended attribute or anything
> included in the HMAC calculation, the existing 'security.evm' is
> verified.  Commit 74de668 "evm: add file system uuid to EVM hmac"
> changed the HMAC calculation method to include the UUID.  If your system
> is already 'security.evm' labeled, for backwards compatibility set
> CONFIG_EVM_HMAC_VERSION to 1.

The problem is also there with a new file (so there is no security.evm xattr
available yet):

#v+
test test # id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video)
context=root:sysadm_r:sysadm_t

test test # pwd
/run/test

test test # ls -la
total 0
drwxr-xr-x. 2 root root  40 Feb 21 19:47 .
drwxr-xr-x. 7 root root 160 Feb 21 19:47 ..

test test # touch foo

test test # getfattr -m . -d foo
# file: foo
security.evm=0sAoOwy0XjhHWculydtncU+R2gRihz
security.selinux="root:object_r:var_run_t"

test test # chmod 0600 foo
chmod: changing permissions of 'foo': Operation not permitted
#v-

I can also confirm it is indeed EVM-related: running with IMA in enforcing
but EVM=fix doesn't show the behavior.

Wkr,
	Sven Vermeulen

Re: [Linux-ima-user] IMA appraisal does not allow changing mode of files

[Mimi Z. <zo...@li...>]

On Tue, 2013-02-19 at 15:40 +0100, Sven Vermeulen wrote:
> Hi all,
> 
> When I try to change the mode on a file in /run, I get a nice error:
> 
> #v+
> chmod: changing permissions of 'utmp': Operation not permitted
> #v-
> 
> When running with ima_appraise=fix evm=fix, the problem doesn't show up.
> Now, I can *read* the files just fine: the files are on a tmpfs, which in
> the policy is said to be not measured and not appraised:
> 
> #v+
> # TMPFS_MAGIC = 0x01021994
> dont_measure fsmagic=0x01021994
> dont_appraise fsmagic=0x01021994
> #v-

These are IMA policy rules, not EVM.  evm_config_xattrnames contains the
list of EVM protected extended attributes.

> The file only holds an EVM hash:
> 
> #v+
> test run # getfattr -m . -d utmp
> # file: utmp
> security.evm=0sAt2bx0ccn9rglgC6yz4RtbkQ0czJ
> security.selinux="system_u:object_r:initrc_var_run_t"
> #v-
> 
> It is just that changing the mode (chmod 0644 utmp) or even SELinux context
> fails:
> 
> #v+
> test run # chcon -t var_run_t utmp
> chcon: failed to change context of 'utmp' to 'system_u:object_r:var_run_t':
> Operation not permitted
> #v-
> 
> I do not get anything in dmesg, audit.log or kern.log. Someone any idea?

Before modifying an EVM protected extended attribute or anything
included in the HMAC calculation, the existing 'security.evm' is
verified.  Commit 74de668 "evm: add file system uuid to EVM hmac"
changed the HMAC calculation method to include the UUID.  If your system
is already 'security.evm' labeled, for backwards compatibility set
CONFIG_EVM_HMAC_VERSION to 1.

Sorry, this sort of problem should definitely be audited.

thanks,

Mimi