Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
> On Fri, Oct 19, 2018 at 10:32 AM,  <valdis.kletnieks@xxxxxx> wrote:
> > What is supposed to happen if some other process has an already existing R/W
> > mmap of the region?  (For that matter, the test program doesn't seem to
> > actually test that the existing mmap region remains writable?)

> Why would it not remain writable? We don't change anything in the
> mapping that prevents it from being writable, in the patch.

OK, if the meaning here is "if another process races and gets its own R/W mmap
before we seal our mmap, it's OK".  Seems like somewhat shaky security-wise - a
possibly malicious process can fail to get a R/W map because we just sealed it,
but if it had done the attempt a few milliseconds earlier it would have its own
R/W mmap to do as it pleases...

On the other hand, decades of trying have proven that trying to do any sort
of revoke() is a lot harder to do than it looks...

> We do test that existing writable mmaps can continue to exist after
> the seal is set, in a way, because we test that setting of the seal
> succeeds.

Well, if the semantics are "We don't bother trying to deal with existing R/W
maps", then it doesn't really matter - I was thinking along the lines of "If we're
revoking other R/W accesses, we should test that we didn't nuke *this* one in
the bargain"....

Attachment: pgp2tw3EvBLpI.pgp
Description: PGP signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux