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

[Mike Frysinger]

On 13 Dec 2015 17:24, Chet Ramey wrote:
> On 12/12/15 4:01 PM, 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:
> 
> It's hard to see how this proposal improves overall system security.  There
> are a dozen ways a minimally-competent attacker can circumvent it.

you're assuming the attacker has unlimited access to resources and control
over the environment and execution.  i already noted there are ways to run
arbitrary code -- when you have arbitrary code access.  there also are cases
(such as i described) which this change would block attacks because the
attacker does not have such unfettered access.  they're leveraging a small
bug elsewhere to escalate to a fuller environment.

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

i'm aware of the fundamental structure of UNIX-like systems.  bash itself
is providing services to a program by executing the requested code and in
a sense, has a responsibility to control that.  otherwise, you seem to be
arguing against the existence of rbash, or job control, or similar shell
limiting/control functionality.

i understand this is a disruptive change.  how about making it a compile
time flag, or perhaps a new shopt ?
-mike

signature.asc
Description: Digital signature