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