On 12 Dec 2015 22:12, John McKown wrote: > On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh > > $ chmod a+rx /dev/shm/test.sh > > $ /dev/shm/test.sh > > bash: /dev/shm/test.sh: Permission denied > > > > But bash itself has no problem running this file: > > $ bash /dev/shm/test.sh > > hi > > Or with letting other scripts run this file: > > $ bash -c '. /dev/shm/test.sh' > > hi > > Or with reading the script from stdin: > > $ 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. > > > > This is not a perfect solution as it can still be worked around by > > inlining the code itself: > > $ bash -c "$(cat /dev/shm/test.sh)" > > hi > > <snip> > > If this is a bug in BASH, then it is likely also a bug in: Python, PERL, > Ruby, LUA, oorexx, <insert scripting language of your choice here>. But, > quite honestly, I haven't checked it out because I don't have a "noexec" > mountpoint handy here at home.
i'm aware. it'd make sense in my mind to have all dynamic interpreters detect the source files before attempting to execute them. i'm looking at shells to start with as they're way more common to be installed and to be a target. -mike
signature.asc
Description: Digital signature
