Re: [RFC 1/1] xattr: provide integrity. namespace to read real values

From: Kasatkin, Dmitry
Date: Mon Feb 25 2013 - 07:25:18 EST

On Thu, Feb 14, 2013 at 9:05 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Wed, Feb 13, 2013 at 11:07:49AM +0200, Dmitry Kasatkin wrote:
>> User space tools use getxattr() system call to read values of extended
>> attributes. getxattr() system call uses vfs_getattr(), which for "security."
>> namespace might get a value of the xattr indirectly from LSM via calling
>> xattr_getsecurity(). For that reason value set by setxattr and read by getxattr
>> might differ.
>> Here is an example of SMACK label, which shows that set and read values are
>> different:
>> setfattr -n security.SMACK64 -v "hello world" foo
>> getfattr -n security.SMACK64 foo
>> # file: foo
>> security.SMACK64="hello"
>> EVM uses vfs_getxattr_alloc(), which directly reads xattr values from the file
>> system. When performing the file system labeling with digital signatures, it is
>> necessary to read real xattr values in order to generate the correct signatures.
>> This patch adds the virtual "integrity." name space, which allows to bypass
>> calling LSM and read real extended attribute values.
>> getfattr -e text -n integrity.SMACK64 foo
>> # file: foo
>> integrity.SMACK64="hello world"
> Without knowing anything about xattr or LSM, to me it is odd that I
> write an xattr using name "security.SMACK64" and read back the same
> attribute using different name "integrity.SMACK64".

It might sound like that, but writing and reading security attributes,
might give different results in security. namespace.
We cannot break userspace and change semantics of calls.
This is a trivial workaround which:
(1) does not to break userspace and
(2) does not require user space modifications.

Please suggest anything else?

- Dmitry

> Thanks
> Vivek
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at