On 3/7/2023 3:56 AM, Mickaël Salaün wrote:
> Let's say an LSM need to pass a file descriptor instead of a text
> value. Would that be possible or would it need to use another interface?
You could use this interface. LSM_ATTR_MAGICFD would have a
ctx_len = sizeof(fd) and the value in ctx. The underlying
plumbing is another matter entirely. It's likely you'd need
to provide more information in the ctx than the fd, but I
couldn't say what it would be, and I won't speculate.
I would not advocate such a use, as I am not now nor have
ever been a fan of passed file descriptors.
>
>
> On 22/02/2023 21:08, Casey Schaufler wrote:
>> Create a system call lsm_get_self_attr() to provide the security
>> module maintained attributes of the current process.
>> Create a system call lsm_set_self_attr() to set a security
>> module maintained attribute of the current process.
>> Historically these attributes have been exposed to user space via
>> entries in procfs under /proc/self/attr.
>>
>> The attribute value is provided in a lsm_ctx structure. The structure
>> identifys the size of the attribute, and the attribute value. The format
>> of the attribute value is defined by the security module. A flags field
>> is included for LSM specific information. It is currently unused and
>> must
>> be 0. The total size of the data, including the lsm_ctx structure and
>> any
>> padding, is maintained as well.
>>
>> struct lsm_ctx {
>> __u64 id;
>> __u64 flags;
>> __u64 len;
>> __u64 ctx_len;
>> __u8 ctx[];
>> };
>>
>> Two new LSM hooks are used to interface with the LSMs.
>> security_getselfattr() collects the lsm_ctx values from the
>> LSMs that support the hook, accounting for space requirements.
>> security_setselfattr() identifies which LSM the attribute is
>> intended for and passes it along.
