[RFC PATCH 0/9] Landlock supervise: a mechanism for interactive permission requests

[Tingmao Wang]

On 3/24/25 10:43, Tetsuo Handa wrote:
> Hello.
>
> On 2025/03/24 10:58, Tingmao Wang wrote:
>> Hi Tetsuo,
>>
>> Thanks for commenting on this RFC and thanks for mentioning TOMOYO - I wasn't
>> aware that another LSM has a similar permission prompting mechanism already
>> (and in fact, I only recently found out AppArmor / Ubuntu has also built
>> something like this [1], although AFAIK it's not upstream'd to mainland Linux,
>> and the current implementation may be somewhat coupled with Snap?), and this
>> is valuable and interesting for me to know :)
>
> I mentioned TOMOYO as an example of how to implement a supervisor feature, for
> there is a pitfall when involving userspace. What is important for implementing
> a supervisor feature is how to avoid deadlocks, for userspace might unexpectedly
> pause due to page fault events. If the supervisor process is blocked due to a
> page fault event, the process which is requesting some access is also blocked.
>
> [...]
>
> For landlock, I guess you assume that the supervisor process is not blocked
> (because landlock is intended for subset of userspace processes), but what if
> the supervisor process tries something that will be blocked by landlock
> (e.g. spawning a userspace program in landlock-controlled environment) ?
> Is there a guarantee that the supervisor process can never request something
> that will be blocked by landlock itself (or other security modules that are
> active) ?

Thanks for raising this and apologies that I missed to reply at the time.
I'm revisiting the supervisor series and these are good points.

For page fault events specifically, I don't think Landlock controls
anything involved in the reading back or writeout of pages (file accesses
are granted or denied at open() time, and as far as I'm aware, page faults
cannot _naturally_ lead to creation of new files or re-opening files), and
so if a supervisor is blocked on a page fault, my claim is that it will
never be due to Landlock itself (And I think perhaps the same is true for
TOMOYO as well - it doesn't look like TOMOYO has any access rights that
can directly be in the path of anything a page fault would need to do
either).  One can presumably set up a situation where, for example, a page
fault in a Landlock supervisor results in a userfaultfd event that needs
to, for some reason, be handled by a process confined by that supervisor,
but this seems unlikely.

Also, for Landlock, the supervisor can only control its "descendants" (but
there is some edge case here - see below).  If a supervisor gets blocked
in Landlock, it will be some parent supervisor above it that needs to
respond, so usually there can't actually be a deadlock from waiting on
Landlock requests (Landlock domains form a tree).

However, if for some reason the supervisor tries to landlock_restrict_self()
itself (i.e. not within a fork), passing in a Landlock ruleset with itself
being the supervisor, such deadlock can happen.  We should probably
disallow landlock_restrict_self() with a process being its own supervisor,
as it doesn't make much sense, doesn't provide security, and can lead to
deadlocks like you mentioned.

Another thing that might happen is if a Landlock supervisor is blocked in
some other LSM (such as TOMOYO), and that LSM requires a reply from a
child process of that supervisor, and that child is blocked in Landlock
waiting for the original supervisor to respond.  I don't have a solution
for this, but this also seems like an unlikely situation that will just
require manual intervention (e.g. killing the supervisor process, which
will then deny the Landlock access request in the child, unblocking it).

Kind regards,
Tingmao