Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #12007
| Path | csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail |
|---|---|
| From | Mike Frysinger <vapier@gentoo.org> |
| Newsgroups | gnu.bash.bug |
| Subject | Re: [PATCH/RFC] do not source/exec scripts on noexec mount points |
| Date | Mon, 14 Dec 2015 00:32:51 -0500 |
| Lines | 78 |
| Approved | bug-bash@gnu.org |
| Message-ID | <mailman.2056.1450071177.31583.bug-bash@gnu.org> (permalink) |
| References | <1449954086-30408-1-git-send-email-vapier@gentoo.org> <566DF00E.9040603@case.edu> |
| NNTP-Posting-Host | lists.gnu.org |
| Mime-Version | 1.0 |
| Content-Type | multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="edOgkofft1yGJ5kl" |
| X-Trace | usenet.stanford.edu 1450071178 26880 208.118.235.17 (14 Dec 2015 05:32:58 GMT) |
| X-Complaints-To | action@cs.stanford.edu |
| Cc | bug-bash@gnu.org |
| To | Chet Ramey <chet.ramey@case.edu> |
| Envelope-to | bug-bash@gnu.org |
| Mail-Followup-To | Chet Ramey <chet.ramey@case.edu>, bug-bash@gnu.org |
| Content-Disposition | inline |
| In-Reply-To | <566DF00E.9040603@case.edu> |
| X-detected-operating-system | by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] |
| X-Received-From | 2001:470:ea4a:1:5054:ff:fec7:86e4 |
| X-BeenThere | bug-bash@gnu.org |
| X-Mailman-Version | 2.1.14 |
| Precedence | list |
| List-Id | Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org> |
| List-Unsubscribe | <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe> |
| List-Archive | <http://lists.gnu.org/archive/html/bug-bash> |
| List-Post | <mailto:bug-bash@gnu.org> |
| List-Help | <mailto:bug-bash-request@gnu.org?subject=help> |
| List-Subscribe | <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe> |
| Xref | csiph.com gnu.bash.bug:12007 |
Show key headers only | View raw
[Multipart message — attachments visible in raw view] - view raw
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
Back to gnu.bash.bug | Previous | Next | Find similar
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points Mike Frysinger <vapier@gentoo.org> - 2015-12-14 00:32 -0500
csiph-web