On 01/06/2023 23:34, Casey Schaufler wrote:

On 6/1/2023 1:48 PM, Jeff Xu wrote:

quoted

Hi Paul,

On Wed, May 31, 2023 at 6:26 AM Mickaël Salaün [off-list ref] wrote:

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

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.