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