From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4689 invoked from network); 30 Jan 2021 18:52:19 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2021 18:52:19 -0000 Received: (qmail 1389 invoked by uid 550); 30 Jan 2021 18:52:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15479 invoked from network); 30 Jan 2021 17:44:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lshxxB3sTcdxeTpgO+ZReuwP3CefBJpzJyZzpMMnz8Q=; b=DzQgS7mqjTvF5i+ovP7C9Yi9OWD57gYzJKqfrFBjcoj71TjUYByBjyDQkvAfkJE+cq uPgpGy6np8t73xY+HJ9HOxou/N8f5658Aa3aY32wHe6Ysp5Izu1/sp4M5oJcZ2WItOfZ ZHoZ70BcWQW1+xWKmO+IEwUSrIp2qIkLIPU2r2gyXBx4q0WfYycyElcw4BopJST++ZsA HHiFdAQzIyIbcqMJcbPpozteiawFI/4LlJme3bkSa1VkYZ3DqvCHB5KMWqcSNhFLWMi1 tDQkbmnAXdirDq5qbHJsgScGWNRuKqg4v79Svnf9ltH/9ESueaqifiRl5bhOxZoARvig I1xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lshxxB3sTcdxeTpgO+ZReuwP3CefBJpzJyZzpMMnz8Q=; b=NExmtp3BPGzsTPK53KlusfSaETs8mrm17z2WtT14wy/zAs48pVhABI++uLNsZA1eZU LFwdwy28SRdGlv7dVnB6OTHGAB543U5LIzFe8Pzbt0e0SPwQLA43jTvw2NUe82pOT2jo UBhspdYrSETxFM9rpt9BCV76DpumjjJRFQTDqsaIZnf8srJ6kEQTkrCJJcVjdSmcAfCT nngjCQ+sio+AXdGfvybOdEJUv++r8ZOKXWRSGpR8supXTutWNuBiBenxGfd1I0KU8mQm huq+4OtYplsqNCylrcE7eduO2DVeiKbCXP8P7AzOehnev0gGRaIEtjyJrkSeJq+oMBAx GIqQ== X-Gm-Message-State: AOAM531txsz/rDqicycKaV+bOUdUaccliPCLpGNqFXOUMr4hvOt/t3M9 Rg4avW8AyTamUlBjqQ8BaBthdq08T/ePamp98EQ= X-Google-Smtp-Source: ABdhPJwgQy1NVJD/cnv/Ys8w36LVmDWcBdZPC/6O/bPQe0uC+nnithA+OW1VUkp0vwrjegHVNQt0b68RB+EtGnrfMtA= X-Received: by 2002:a19:88b:: with SMTP id 133mr5143797lfi.449.1612028687857; Sat, 30 Jan 2021 09:44:47 -0800 (PST) MIME-Version: 1.0 References: <20210124154026.GR23432@brightrain.aerifal.cx> <20210124181036.GS23432@brightrain.aerifal.cx> <20210124185545.GT23432@brightrain.aerifal.cx> In-Reply-To: <20210124185545.GT23432@brightrain.aerifal.cx> From: Andrew Rogers Date: Sat, 30 Jan 2021 17:44:36 +0000 Message-ID: To: Rich Felker Cc: Alexander Monakov , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000004ebdc205ba21adb7" Subject: Re: [musl] Potential DL_NOMMU_SUPPORT bug. --0000000000004ebdc205ba21adb7 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 24, 2021 at 6:55 PM Rich Felker wrote: > On Sun, Jan 24, 2021 at 09:48:11PM +0300, Alexander Monakov wrote: > > > > sdcard [pseudo-]partition is usually mounted noexec, so mmap with > PROT_EXEC > > > > should fail. > > > > > > Uhg, that makes no sense. Does it enforce that even for MAP_PRIVATE, > > > which should semantically be equivalent to just making anon memory > > > with the requested permissions and copying the file contents into it?? > > > > I think it makes sense: isn't the entire point of 'noexec' that a user > > who has write access only to noexec filesystems will not be able to run > > arbitrary binary code (assuming the already-present binaries are not > > cooperative, unlike musl ld.so with the above patch would be)? Enforcing > > noexec for MAP_PRIVATE ensures the users can not trivially side-step > > noexec by invoking ld.so (without extra checks on ld.so side). > > I always viewed noexec (as opposed to something like nosuid) as a > non-security-boundary, a sort of soft block for mounting filesystems > that you don't want to execute programs from, for example a disk image > known to contain malware that you're analyzing or a flash drive not > expected to contain meaningful executable data but where all files > would appear as +x due to FAT limitations. The expectation is that it > can be bypassed. With a "restricted shell" type environment (very > careful selection of what programs are present), it can plausibly be > turned into a (very fragile) security boundary, but I didn't expect > the kernel to be making weird rules to facilitate that. > > In any case, it seems that's how it is, and inability to dlopen (or > LD_LIBRARY_PATH+DT_NEEDED or whatnot) from a noexec mount is > annoying... > > Rich > Thank you very much for your responses. I am reassured that there is no bug and that my patch just provides a convenient workaround for my use case. Albeit by accident rather than design! I am attempting to load binary executables and shared libraries from the sdcard on Android. My patch does allow me to execute the busybox binary from sdcard if I load them using my patched musl. I have not yet tried loading any shared libraries from the sdcard. An alternative I am experimenting with at the moment is using LLVM and storing the bitcode on the sdcard and running it under lli. Your responses are very informative so I might have another look at patching musl to see if shared libraries can be loaded from sdcard also. The dlopen function will probably need to be reworked to use open rather than mmap but I need to learn some more first! Many thanks, Andrew --0000000000004ebdc205ba21adb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jan 24, 2021 at 6:55 PM Rich Felker <dalias@libc.org> wrote:
On Sun, Jan 24, 2021 at 09:48:11PM +0300,= Alexander Monakov wrote:
> > > sdcard [pseudo-]partition is usually mounted noexec, so mmap= with PROT_EXEC
> > > should fail.
> >
> > Uhg, that makes no sense. Does it enforce that even for MAP_PRIVA= TE,
> > which should semantically be equivalent to just making anon memor= y
> > with the requested permissions and copying the file contents into= it??
>
> I think it makes sense: isn't the entire point of 'noexec'= that a user
> who has write access only to noexec filesystems will not be able to ru= n
> arbitrary binary code (assuming the already-present binaries are not > cooperative, unlike musl ld.so with the above patch would be)? Enforci= ng
> noexec for MAP_PRIVATE ensures the users can not trivially side-step > noexec by invoking ld.so (without extra checks on ld.so side).

I always viewed noexec (as opposed to something like nosuid) as a
non-security-boundary, a sort of soft block for mounting filesystems
that you don't want to execute programs from, for example a disk image<= br> known to contain malware that you're analyzing or a flash drive not
expected to contain meaningful executable data but where all files
would appear as +x due to FAT limitations. The expectation is that it
can be bypassed. With a "restricted shell" type environment (very=
careful selection of what programs are present), it can plausibly be
turned into a (very fragile) security boundary, but I didn't expect
the kernel to be making weird rules to facilitate that.

In any case, it seems that's how it is, and inability to dlopen (or
LD_LIBRARY_PATH+DT_NEEDED or whatnot) from a noexec mount is
annoying...

Rich

Thank you ve= ry much for your responses. I am reassured that there is no bug and that my= patch just provides a convenient workaround for my use case. Albeit by acc= ident rather than design!

I am attempting to l= oad binary executables and shared libraries from the sdcard on Android. My = patch does allow me to execute the busybox binary from sdcard if I load the= m using my patched musl. I have not yet tried loading any shared libraries = from the sdcard.

An alternative I am experimenting= with at the moment is using LLVM and storing the bitcode on the sdcard and= running it under lli.

Your responses are very inf= ormative so I might have another look at patching musl to see if shared lib= raries can be loaded from sdcard also. The dlopen function will probably ne= ed to be reworked to use open rather than mmap but I need to learn some mor= e first!

Many thanks,
Andrew
=C2=A0
--0000000000004ebdc205ba21adb7--