t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger <vap...@gentoo.org> wrote: > On 13 Dec 2015 16:50, konsolebox wrote: >> On Sun, Dec 13, 2015 at 5:01 AM, 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 (s) 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. > > (1) the examples i already provided do not involve the user at all, and > include systems where the user has no direct access to the shell.
And the one that made the code execute remotely through for example an exploit is not a user? Also consider use of `source` or `eval` may it be in a subshell or not. eval "$(cat /path/script.sh)" source <(cat /path/script.sh) > (2) choice over runtime functionality is by the sysadmin, not the user. Doesn't matter to me. And I'm referring to the real user or the person, and not the account. I don't want an inconsistent functionality running in my bash whether I'm using a privileged account or not. > (3) i disagree over the scope of noexec. i think this is in-scope. Being a little forgiving, I could say that scripts with #! headers -perhaps- are still in the scope of `noexec` since they are respected by the kernel as executables, even though they are not real instructions running within the processor's transistors themselves (they are just read and -virtually- executed where the shell acts on behalf of them), but how about those scripts without #! headers? Clearly they're no longer -executables-. And clearly you're just wanting bash to restrict things based on the conceptual purpose of `noexec`, even though it is not exactly or strictly in the scope of `noexec`. I'm a purist and I don't like that, and I don't want to have that inconsistency in default bash.
