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

[Chet Ramey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/14/15 12:32 AM, Mike Frysinger wrote:
> 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.  Th
ere
>> are a dozen ways a minimally-competent attacker can circumvent it.
> 
> you're assuming the attacker has unlimited access to resources and contro
l
> over the environment and execution.  

Of course -- that's the general case.  You're talking about changes to a
general tool installed in such environments.



> i already noted there are ways to run
> arbitrary code -- when you have arbitrary code access.  there also are ca
ses
> (such as i described) which this change would block attacks because the
> attacker does not have such unfettered access.  they're leveraging a smal
l
> bug elsewhere to escalate to a fuller environment.

What's the intended set of systems for which this would be useful?


>> A worse problem is that the abstraction is in the wrong place.  The shel
l,
>> like other programs, requests services from the kernel to do things.  Th
e
>> 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 system
s
>> 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.

Yes, I know you are.  I'm placing my point in context.

> bash itself
> is providing services to a program by executing the requested code 

I suppose you can make that argument, but I don't think it fits within what
I understand the intent of `noexec' to be.

> 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 actually think rbash is kind of useless.  In the case of job control,
or ulimit, or trap, or cd, the shell is exposing kernel functionality to
the user and allowing him to access it.

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

It depends on the set of intended target systems and the users' scope of
access to the entire system.  On some captive system like a chromebook or
a linux-based video player (like an airplane seat-back player, for
instance), I can see a compile-time flag making sense.  I don't think this
has a place on a general-purpose user system.

- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZxzE0ACgkQu1hp8GTqdKv0bACfb3m6AM0N59cQZJkWe3GYFwKb
Ic0An28bMKeihs7sVsfG9EXoFCB0MGmH
=ALQH
-----END PGP SIGNATURE-----