mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Andrew Rogers <andrew.rogerstech@gmail.com>
To: Rich Felker <dalias@libc.org>
Cc: Alexander Monakov <amonakov@ispras.ru>, musl@lists.openwall.com
Subject: Re: [musl] Potential DL_NOMMU_SUPPORT bug.
Date: Sat, 30 Jan 2021 17:44:36 +0000	[thread overview]
Message-ID: <CAFrSoMzastsKU+oO=3s7VMetK0qaqgCy3EVAXVxZwp0=K4GNWA@mail.gmail.com> (raw)
In-Reply-To: <20210124185545.GT23432@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

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_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

[-- Attachment #2: Type: text/html, Size: 3283 bytes --]

  reply	other threads:[~2021-01-30 18:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-23  6:47 Andrew Rogers
2021-01-24 15:40 ` Rich Felker
2021-01-24 15:58   ` Alexander Monakov
2021-01-24 18:10     ` Rich Felker
2021-01-24 18:48       ` Alexander Monakov
2021-01-24 18:55         ` Rich Felker
2021-01-30 17:44           ` Andrew Rogers [this message]
2021-01-30 19:01             ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFrSoMzastsKU+oO=3s7VMetK0qaqgCy3EVAXVxZwp0=K4GNWA@mail.gmail.com' \
    --to=andrew.rogerstech@gmail.com \
    --cc=amonakov@ispras.ru \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).