[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 30 Jan 2021 14:01:30 -0500
From: Rich Felker <dalias@...c.org>
To: Andrew Rogers <andrew.rogerstech@...il.com>
Cc: Alexander Monakov <amonakov@...ras.ru>, musl@...ts.openwall.com
Subject: Re: Potential DL_NOMMU_SUPPORT bug.
On Sat, Jan 30, 2021 at 05:44:36PM +0000, Andrew Rogers wrote:
> On Sun, Jan 24, 2021 at 6:55 PM Rich Felker <dalias@...c.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...
>
> 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!
If the system is setup to gratuitously disallow direct PROT_EXEC
mapping from the filesystem, I would just drop the binaries in a tmpfs
and load them from there.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
