On Sat, Jul 13, 2024 at 10:58:58PM +0200, Steffen Nurpmeso wrote:
> Jacob Bachmeyer wrote in
> <6691e39c.8090...@gmail.com>:
> |Steffen Nurpmeso wrote:
> |> [...]
> |>
> |> So if someone says "this was a source of
> |> denial‐of‐service attacks" then i need to wrap my head, and it is
> |> not as if an in-between-the-lines reference to MAP_DENYWRITE ring
> |> any bells except that i think the flag has been removed.
> |
> |The manpage indicates that, long ago, a mapping with MAP_DENYWRITE would
> |effectively make the underlying file read-only, even to root, for as
> |long as the mapping exists.
>
> Thank you. I add a search result from Google Groups which still
> exists for doing so collected just now:
>
> Linus Torvalds Oct 4, 2001, 7:38:12 AM
>
> Rob Landley <lan...@trommello.org> wrote:
> >I.E. it seems like they go out of their way to ALLOW writing to the
> libaries.
> > (I assume they KNOW the difference between MAP_DENYWRITE, MAP_COPY, and
> >MAP_PRIVATE...?)
>
> Note that the kernel will refuse to honour MAP_DENYWRITE from user
> space, so I'm afraid that changing ld.so won't do a thing.
>
> The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
> excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
> and even root cannot write to it.. Vary nasty.
>
> Which is why the kernel only allows it when the binary loader itself
> sets the flag, because security-conscious application writers are
> already aware of the "oh, a running binary may not be writable" issues.
>
> So sorry..
>
> Linus
>
> Linus Torvalds Oct 4, 2001, 7:49:27 AM
>
> On Thu, 4 Oct 2001, Alexander Viro wrote:
> > <nit>
> > I _really_ doubt that something does write() on /etc/passwd. Create a
> > file and rename it over the thing - sure, but that's it.
> > </nit>
>
> Well, yeah, bad choice. Can you believe /var/run/utmp or similar?
>
> And yes, we could add checks for the thing being executable before we
> accept MAP_DENYWRITE instead of just ignoring the flag from user space.
> Nobody has cared enough to make the effort.
>
> Until now?
>
> Linus
>
> Some findings:
> . I note that the mentioned files are writable by only root (and
> i would assume MAP_DENYWRITE to only work if i could do so
> myself).
> . Capabilities have become more fine-grained.
> . I always whimper when i have to rm(1) a running executable before
> placing an updated variant on Linux, on BSDs i simply over-cp(1)
> (and i do not understand as long as one gets either the one or
> the other when executing the path).
> . Shouldn't mandatory file locking have the same effect.
> But it is ok to me, Linux is as it is, and they progress and
> iterate over the code at an unbelievable speed. And some things
> are just the way they are. (Or change. Back. And forth. And
> back etc etc)Executable files and shared libraries should _never_ be modified in-place. They should _always_ be renamed over. Otherwise, a program might be a mixture of the old and new version, with completely undefined results when the program is run. > |> And then > |> someone who seems to know uses it nonetheless in a small showcase > |> program, likely trying to say even more in-between-the-lines. > | > |That commit message seems to indicate that the program was using > |SHM_HUGETLB when it should have been using MAP_HUGETLB, those constants > |represent different bits, and passing SHM_HUGETLB to mmap(2) will be > |interpreted as MAP_DENYWRITE, and therefore ignored. Presumably, there > |is some other syscall (likely shmat(2)) that uses that bit (represented > |under the constant SHM_HUGETLB) to request huge pages, and the test > |program in question was supposed to get huge pages from mmap(2) but was > |not actually asking for huge pages because it was using the wrong constant. > | > |In other words, MAP_DENYWRITE was not being intentionally used at all. > |Another constant, for a different set of flags, that happens to have the > |same value, was being used, causing a quiet bug. (The test program > |would have still worked, but was not actually exercising huge pages as > |intended.) > > The Linux commit messages are tremendous books that often leave me > stunning. I *never* get together such things in my own work > process. So thanks for spending additional time reiterating this. > > |-- Jacob > > Thank you very much. > > --End of <6691e39c.8090...@gmail.com> > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
signature.asc
Description: PGP signature
