[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.
- [PATCH/RFC] do not source/exec scripts on noexec mount points, Mike Frysinger, 2015/12/12
- Re: [PATCH/RFC] do not source/exec scripts on noexec mount points, John McKown, 2015/12/12
- Re: [PATCH/RFC] do not source/exec scripts on noexec mount points,
konsolebox <=
- Re: [PATCH/RFC] do not source/exec scripts on noexec mount points, Chet Ramey, 2015/12/16
- Re: [PATCH/RFC] do not source/exec scripts on noexec mount points, John McKown, 2015/12/16
- Re: [PATCH/RFC] do not source/exec scripts on noexec mount points, Chet Ramey, 2015/12/16
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points, Stephane Chazelas, 2015/12/13