On 12/12/15 4:01 PM, Mike Frysinger wrote:
> From: Mike Frysinger <vap...@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:
It's hard to see how this proposal improves overall system security. There
are a dozen ways a minimally-competent attacker can circumvent it. Unless
you want to completely remove the ability for bash and other utilities to
read files from a noexec file system, or run on a system with no writable
file systems at all, this does no good. Its primary effect would seem to
be annoying and frustrating users.
A worse problem is that the abstraction is in the wrong place. The shell,
like other programs, requests services from the kernel to do things. The
kernel is the arbiter of restrictions on those services. If asked to
execute a file, the shell asks the kernel whether the file is executable,
then tries to execute it. If asked to read a file, the shell tries to
open it. The kernel, or some agent it invokes, is where the access
decision is made. If you want to, for instance, disallow the shell and
other utilities from opening executable files for reading on file systems
with noexec set, the shell binary is not the place to embed that policy.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
