Re: Denial of service attack via libpager

[Richard Braun]

On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote:
> So we still have to mmap across the network.  We certainly don't want to
> avoid mmap's entirely for program text and (especially) for shared
> libraries.  Although I admit that it would be best to detect when the mmap
> fails and fall back on ordinary reads.

Again, we could avoid mmap entirely by passing memory out-of-line,
with copy-on-write zero-copy. When I say zero-copy, it means that the
underlying memory will not be actually copied until accessed.

> The obvious additional client would be a remote kernel, but as the exploit
> program that I posted shows, it could just as easily be an unprivileged
> process.  You don't need much permission to get a memory object, just read
> access on the file.

OK, this comes from the fact that io_map directly provides memory
objects indeed... Do we actually want to pass them around ? How
come calls like memory_object_init (specifically meant to be used
between the kernel and the pager) can be made from any client ?

If we don't want to pass them around, we could instead let the
server handle the mapping on behalf of the client, but this violates
Hurd's principle of "mutually untrusting clients and servers".
Although I personally believe this principle is impossible to apply
in practice (one basic denial of service is to merely sleep and never
wake up, where an explicit action from the user is required to break
the ipc call, no different in practice from killing a process),
I recognize the user might want to apply his own policy to the
mapping, so it might be advantageous to allow passing the memory
objects anyway.

If we consider Unix as a reference, then the map call uses a file
descriptor. It's equivalent to a memory object because the translation
is done privately in the kernel, but we could also change the
mapping interface to provide some proxy object to the client,
which could be thought of as an unprivileged memory object.
When mapping, the kernel would then invoke the proxy object to
obtain the memory object, which, in addition to replacing mmap
with COW zero-copy, solves the problem. What I'm stressing here
is the importance of viewing a memory object as a private
communication channel between the kernel and a pager.

The changes involved here are heavy, which is one reason we'd want
to avoid them. It also makes the system slightly slower by adding
a new layer of abstraction. So we may just want to support multiple
clients at the pager level, but I really don't see the benefit
other than "it works". You really need to justify why it's a good
thing that any unprivileged client is allowed to perform memory
object management calls...

-- 
Richard Braun