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.3 required=5.0 tests=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 5930 invoked from network); 30 Jan 2021 19:01:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2021 19:01:46 -0000 Received: (qmail 5320 invoked by uid 550); 30 Jan 2021 19:01:44 -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 5302 invoked from network); 30 Jan 2021 19:01:43 -0000 Date: Sat, 30 Jan 2021 14:01:30 -0500 From: Rich Felker To: Andrew Rogers Cc: Alexander Monakov , musl@lists.openwall.com Message-ID: <20210130190129.GO23432@brightrain.aerifal.cx> References: <20210124154026.GR23432@brightrain.aerifal.cx> <20210124181036.GS23432@brightrain.aerifal.cx> <20210124185545.GT23432@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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