bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: konsolebox
Subject: Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
Date: Sun, 13 Dec 2015 16:50:07 +0800

On Sun, Dec 13, 2015 at 5:01 AM, 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
>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]