On 18/05/2023 22:44, Shervin Oloumi wrote:
[...]
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.
It would work the same as proc/self/fd, but may require some API changes
to be in line with the LSM API. Relying on the LSM syscalls would not
require to change this API.
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).
I really want the concept I proposed to be used: a sandbox process
should not be able to get any data from processes in the same sandbox
(except through side effects such as nesting limit) nor for processes
not in a nested sandbox. In fact, this should just use
ptrace_may_access() (as already done for sensitive procfs files), and
checking the current domain as you did.
