[PATCH 0/1] process attribute support for Landlock

[Casey Schaufler]

On 3/2/2023 10:52 AM, enlightened at chromium.org wrote:
> From: Shervin Oloumi <enlightened at chromium.org>
>
> Hi Mickaël,
>
> I'm looking into adding a simple process attribute getter to Landlock so
> we can determine the sand-boxing state of each process based on
> /proc/[PID]/attr/current. As ChromeOS is expanding Landlock support,
> this would help us paint a clear picture of Landlock coverage in the
> fleet. I prepared a patch as a starting point, and would love to get
> your feedback.
>
> One area I am not very sure of is the case where more than one LSM is in
> use. In such cases each LSM could have its own process attribute
> getters and setters. What I learned is that when this is the case, the
> kernel only calls the hook function for the LSM that is loaded first in
> the CONFIG_LSM option. For example if landlock comes first
> (CONFIG_LSM=landlock,...), then the kernel only calls the hook function
> for Landlock, when the userspace interacts with process attribute files.
> This is not a blocker for us, as we only currently care about reading
> the Landlock related attributes, and my understanding is that this is
> working as intended, but wanted to get your input.

Emphasis: DO NOT USE /proc/.../attr/current! Seriously!

I made a huge mistake reusing current in Smack. If you want to
provide a Landlock attribute in /proc create a new one. Long term
we're trying to move to a syscall interface (patches in review).
But for the time being (and backports) a new name in attr is easy
enough to do and will avoid many headaches. Better yet, a subdirectory
in attr - /proc/.../attr/landlock - will avoid all sorts of issues.


>
> Shervin Oloumi (1):
>   lsm: adds process attribute getter for Landlock
>
>  fs/proc/base.c         | 11 +++++++++++
>  security/landlock/fs.c | 33 +++++++++++++++++++++++++++++++++
>  2 files changed, 44 insertions(+)
>
>
> base-commit: e2ca6ba6ba0152361aa4fcbf6067db71b2c7a770