Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Mike Frysinger Newsgroups: gnu.bash.bug Subject: Re: [PATCH/RFC] do not source/exec scripts on noexec mount points Date: Sat, 12 Dec 2015 17:53:35 -0500 Lines: 78 Approved: bug-bash@gnu.org Message-ID: References: <1449954086-30408-1-git-send-email-vapier@gentoo.org> <20151212144836367922988@bob.proulx.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AouxlZHmRoNegvUM" X-Trace: usenet.stanford.edu 1449960823 29820 208.118.235.17 (12 Dec 2015 22:53:43 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org Mail-Followup-To: bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <20151212144836367922988@bob.proulx.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 140.211.166.183 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11993 --AouxlZHmRoNegvUM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12 Dec 2015 15:06, Bob Proulx wrote: > Mike Frysinger wrote: > > But bash itself has no problem running this file: > > $ bash /dev/shm/test.sh > > hi > >... > > This detracts from the security of the overall system. People > > writing scripts sometimes want to save/restore state (like > > variables) and will restore the content from a noexec point using > > the aforementioned source command without realizing that it executes > > code too. Of course their code is wrong, but it would be nice if > > the system would catch & reject it explicitly to stave of > > inadvertent usage. >=20 > I don't think it makes sense for a userland program to be an enforcer > of this type of check. It gives a false impression of a security that > does not exist. Which I think is more dangerous. i disagree, and it's the right place imo: the program that does the interpreting in the first place (i.e. the shell) should be checking for the settings where it's going to be loading that interpreted code. the reason binary loaders (e.g. ELF ldso's) don't need to do this is the kernel either prevents it directly (`./foo`) or indirectly (when the ldso tries to mmap the file with exec bits, the kernel will check for the noexec mount setting). > It will almost > certainly get in the way of a reasonable use case. can you name a reasonable use case this breaks ? > And nothing > prevents one from running a private copy of a shell without such a > check. Or any of the many compatible /bin/sh variants such as ksh, > zsh, ash, dash, and so forth. you're assuming (1) the user has access to a writable && exec mount point and (2) those other shells are installed. clamping both of those loop holes are trivial and i've seen a number of systems that do exactly that. Chrome OS for example only mounts / as executable and that is also read only. i imagine other verified boot systems enforce similar sanity, as do remote hosts (a number of systems i have ssh access do this). i also plan on sending patches for shells i care about (e.g. dash). -mike --AouxlZHmRoNegvUM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWbKVvAAoJEEFjO5/oN/WBITUP/RNC452OFT+KSm3+xmCcPvNf rcM5me4lw/oHmMjN3aad70xd0KCki/y4A9jCkDQpuKv1YEwfBBrX9B8aUgA9utN2 MhzRHE34rqqOO0FhOoX37Z1fxvo5hhYC4p0svzNnygKVSoPZwvvBG/z9d/eIJdme T4rR2fIp4bEIKumIJzCeKYNjoPhp6Wrywv+naL1MG1+uHsLJCSLsmk7YW9xPOg0+ qFKxidIHevAAxhsTMiXbZsxEULs50XP0V6uLn1koaND1pwhx46eKXmjJl4j+h3+/ edPWNw7x1sUZPkSOgqoofFwfYtS9rbRIFvyuuT53IMEN+0QJq7POKZHwYiG/x9UM w3G05PLWMA2bD/NDq/Pgua61JBbI39+GV9yIBvCWE3E5YV1ODpY/W2nAhg1uqFoE 00UB+k0xnRgPLohDuYwjMh55Srgg3m0rMWLwcfqDvTubEIA1fEOQp78xnBXdl8wN cje1v2+fLxstmFkJE5Z7ggMEbo01V1gUyp1XzhWpoIvJa6akbTKB172+zie27i+t /XNppUz07i67bBGdfwQW1OAjxENIFgV5w6yJ2YhdBTQ1UB5w7XspHOg/wXtgoFVC RvZq2P4bZWC0876s1jsWnVfMnHwVfWN9eorAYnJSohslTkViMOJGVOG8XyWukAGG R+CCcOO1KckTrxQVgSbT =TAYW -----END PGP SIGNATURE----- --AouxlZHmRoNegvUM--