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@xxxxxxxxxxx> 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.
