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

[konsolebox]

t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger <vapier@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.