Re: gnumach RPC: get info about the calling task

[Sergey Bugaev]

On Tue, Oct 12, 2021 at 3:37 PM Joan Lledó <jlledom@mailfence.com> wrote:
> Hi,
>
> I'm working on the gnumach rpc to return a pager from a task and an
> address mapped in that task.

Cool! What's the RPC signature?

> For security reasons I'd like to check if the calling task is the same
> as the one the given map belongs to. But I don't know how to do it.

Please don't do this. This is very much against how capability
systems, and Mach / Hurd in particular, are designed. In capability
systems, it should never ever matter *who's* making a call; the only
important thing is whether they have a relevant capability or not. In
other words, this makes Mach RPC caller-transparent; it matters which
messages are sent to which destination, but not who sends them.

This (beautiful!) property/invariant is what allows you to manipulate
any task that you have a task port of, not just your own task. This is
used, for example, by the exec server to destroy and create threads
and manipulate memory mappings of the task being exec'd. This is also
used to manipulate the just-created "child" task in fork (), and
likely in many other places.

Finally, consider rpctrace: it intercepts, traces, and re-sends every
single message coming from or to the traced task. If the kernel would
check who the caller is, it would see that the caller is rpctrace and
not the task, and that would presumably affect its behavior somehow
(such as make it reject some calls). The whole idea of rpctrace is
predicated on the invariant that the caller identity *doesn't* affect
the servers' behavior.

So in the case of vm_map-backed pager, it should matter whether you
have a task port to the target task, not whether you *are* the target
task. If someone has a task port to a task, it allows them to
completely control the task anyway (including making it invoke any
RPC); there's no additional security gains from checking who the
caller is, but there will be additional breakage.

> In the rpc implementation, the function receives a vm_map_t parameter.
> How can I get the task from the vm_map_t?

You'd declare the argument as task_t instead of vm_task_t; that would
make the kernel-side C handler accept a task_t instead of a vm_map_t.
The user code passes a task port in either case.

> and how can I compare it with
> the calling task to check whether it's the same?

You can get the current (calling) task with the current_task () macro
(see kern/thread.h). Or in fact you could get the vm_map directly by
using the current_map () macro from the same file; then you could
compare that against the vm_map_t you already have; so you wouldn't
even need to do what I've said above (make your handler to accept a
full task_t).

But again, please don't do this.

Sergey