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