[PATCH 0/1] process attribute support for Landlock

[Mickaël Salaün]

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.