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).
