[CRIU] [PATCH v2] lsm: adds process attribute getter for Landlock

[Mickaël Salaün]

On 01/06/2023 23:34, Casey Schaufler wrote:
> On 6/1/2023 1:48 PM, Jeff Xu wrote:
>> Hi Paul,
>>
>> On Wed, May 31, 2023 at 6:26 AM Mickaël Salaün <mic at digikod.net> wrote:
>>>>>>
>>>>> If I understand correctly:
>>>>> 1> A new lsm syscall - lsm_get_pid_attr():  Landlock will return the
>>>>> process's landlock sandbox status: true/false.
>>>> There would have to be a new LSM_ATTR_ENFORCMENT to query.

I guess there is a misunderstanding. What is the link between global 
system enforcement and the status of a sandboxed/restricted/enforced(?) 
process?

The attribute would then be something like LSM_ATTR_RESTRICTED to get a 
process restriction status, which might be the same for all processes 
with system-wide policies (e.g., SELinux) but not for Landlock.


>>>> Each LSM could then report what, if any, value it choose to.
>>>> I can't say whether SELinux would take advantage of this.
>>>> I don't see that Smack would report this attribute.
>>> I think such returned status for LSM_ATTR_ENFORCMENT query would make
>>> sense, but the syscall could also return -EPERM and other error codes.
>>>
>>>
>>>>> Is this a right fit for SELinux to also return the process's enforcing
>>>>> mode ? such as enforcing/permissive.
>>> Paul could answer that, but I think it would be simpler to have two
>>> different queries, something like LSM_ATTR_ENFORCMENT and
>>> LSM_ATTR_PERMISSIVE queries.
>>>
>> Hi Paul, what do you think ? Could SELinux have something like this.
> 
> Not Paul, but answering anyway - No, those are system wide attributes, not
> process (task) attributes. You want some other syscall, say lsm_get_system_attr()
> for those.