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 6173 invoked from network); 24 Jan 2021 18:56:01 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Jan 2021 18:56:01 -0000 Received: (qmail 30588 invoked by uid 550); 24 Jan 2021 18:55:58 -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 30566 invoked from network); 24 Jan 2021 18:55:57 -0000 Date: Sun, 24 Jan 2021 13:55:45 -0500 From: Rich Felker To: Alexander Monakov Cc: musl@lists.openwall.com, Andrew Rogers Message-ID: <20210124185545.GT23432@brightrain.aerifal.cx> References: <20210124154026.GR23432@brightrain.aerifal.cx> <20210124181036.GS23432@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 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