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

[Mike Frysinger]

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

(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.
(2) choice over runtime functionality is by the sysadmin, not the user.
(3) i disagree over the scope of noexec.  i think this is in-scope.
-mike

signature.asc
Description: Digital signature