Re: [PATCH 0/1] process attribute support for Landlock

[Shervin Oloumi <enlightened@chromium.org>]

Sorry for the delay on this. I think there is a fundamental issue here
that needs to be resolved first, and that is the limitation of the
kernel that only one LSM's hook function can be called through the
procfs attribute interface. This is a blocker for us (and I imagine
for others), since implementing any LandLock attribute API would block
the existing SELinux hook function, which is used to surface domain
information. `ps` also uses it to display domain information when you
pass `-Z`. Please note, this is independent of which path and filename
we use for LandLock. Even when the "domain" file is placed under a
different directory, for example `/proc/[pid]/attr/landlock/domain`
the kernel only calls the Landlock hook function for any interaction
with any files under attr (the kernel always calls only the hook
function for the first loaded LSM in the kernel config). So if anyone
in this thread has any information on whether there is work on
progress for addressing this issue, that would be helpful.

As for the patch, I will just provide what I have so far, which I
think is more in line with the approach you suggested, so that it can
perhaps at some point be useful, once the above limitation is
resolved.

> Yes, the approach I suggested, check the /proc/.../attr/landlock/domain
> presence would enable you to check the landlocked state of a process. It
> should not change much from your initial patch. In fact it will be
> quicker to check because there is no need for the open/read/close
> syscalls, but only faccessat2.

I played around with this idea but ran into a problem; I'm not sure if
it is possible to implement a behavior where the existence/viewability
of the `/proc/.../attr/landlock/domain` is conditional. The `domain`
file is predefined with set permissions in `fs/proc/base.c` (as done
in the patch) and it is always present if landlock is enabled.
Additionally, the `landlock_getprocattr` hook function only gets
called when the file `/proc/.../attr/landlock/domain` is opened and
read, so I'm not sure how the file visibility can be manipulated.

The closest way I can think of to imitate the suggested behavior is to
return `EACCES` in the hook function if the checking process domain is
not related to the target process domain and return "none" (indicating
there is no Lanldock domain associated with this process) if the
domain check passes and the target process is not landlocked. In cases
where the access check passes (or when the checking process is not
landlocked) and the target process is landlocked reading the file
could just return nothing (maybe in the future this will return the
domain ID...TBD).