Re: [PATCH/RFC] do not source/exec scripts on noexec mount points

[John McKown]

On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger <vapier@gentoo.org> wrote:

From: Mike Frysinger <vapier@chromium.org>

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.​

 

--

Schrodinger's backup: The condition of any backup is unknown until a restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown