On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger <vap...@gentoo.org> wrote: > From: Mike Frysinger <vap...@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 > > But this makes things a bit harder for malicious attackers (depending > how exactly they've managed to escalate), but it also helps developers > from getting it wrong in the first place.
Application-level based security on an environment where people using the application has direct control over the environment for me is not so sensible, and is a dirty hack. A shell is also not meant for that. If you want such feature perhaps you should add it on a restricted shell, granting it really makes sense adding it. But forcing that feature to be default on every user (like me who doesn't want its inconsistency) is wrong. A shell reads and executes and is something not in the scope of `noexec`, not in the scope of kernel-land security, so we have to deal with it.
