LWN: Comments on "O_MAYEXEC — explicitly opening files for execution"

O_MAYEXEC — explicitly opening files for execution

robbe — Tue, 19 May 2020 13:58:08 +0000

Would it change anything if CLIP OS were a BSD variant?

I’d support the popularity argument – an OS used by n people should not be hobbled by an OS that only n/10000 people use. But genealogy should not play into it.

O_MAYEXEC — explicitly opening files for execution

neilbrown — Sat, 16 May 2020 05:15:51 +0000

I see the cut-line a different way.

Unless an application is configured to be careful about what it runs, then it doesn't ever set the flag.
So if /bin/sh will accept "-c code" on the command line, and will execute code read from stdin, then it will equally execute code read from a file opened without O_MAYEXEC, and so never bothers to set O_MAYEXEC.

But is it has been configured - either at compile-time or by some /etc/bash-security.conf file - to disable -c and reading from stdin, then it will set O_MAYEXEC whenever it opens any file to read commands.

Similarly any other app, whether browser or music player or editor, might accept a "be secure" configuration which causes it to start using O_MAYEXEC. If "secure" isn't uni-valued for the particular app, then the configuration will fill in the details.

O_MAYEXEC isn't a tool to enforce security. It is a tool to help people who so desire to build more secure systems. The person who builds the final system decides what O_MAYEXEC means exactly, just as they choose what permissions to put on different files.

O_MAYEXEC — explicitly opening files for execution

mjg59 — Fri, 15 May 2020 19:34:00 +0000

A browser could try to open with O_MAYEXEC, and if that fails fall back to opening without it but disabling the Javascript interpreter.

O_MAYEXEC — explicitly opening files for execution

l0kod — Fri, 15 May 2020 18:35:04 +0000

> Does this mean, then, that I should remove the current O_MAYEXEC support from mksh?

Yes, you can.

> There’s no way it, as a portable application, is going to use a different syscall for opening, though.

If you want to use different features from different OS, then you can use #ifdef and such. There is a lot of applications and libraries implementing differently similar features (e.g. managing temporary files with mkstemp, O_TMPFILE, etc.).

> I’m getting the hint that CLIP OS 5 would also use openat2() only, then.

It is planned to use upstream features as much as possible.

O_MAYEXEC — explicitly opening files for execution

amarao — Fri, 15 May 2020 18:03:27 +0000

Where is the cut line for this flag? If browser is reading file://path/script.js, is this an 'may exec'? If so, is HTML file may exec? They can contain js...

Is ansible playbook 'exec'? Is ansible inventory 'exec'? It may contain variables with Jinja templates and 'command' lookup plugin, which is local code execution by the way.

The border line is extremely blurry. Is mailbox executed by mua? It may contain js...

O_MAYEXEC — explicitly opening files for execution

mirabilos — Fri, 15 May 2020 16:11:57 +0000

Thanks for responding here.

Does this mean, then, that I should remove the current O_MAYEXEC support from mksh?

There’s no way it, as a portable application, is going to use a different syscall for opening, though.

I’m getting the hint that CLIP OS 5 would also use openat2() only, then.

O_MAYEXEC — explicitly opening files for execution

l0kod — Fri, 15 May 2020 08:31:31 +0000

I'm the main O_MAYEXEC (upstream patch series) developer, and I've developed CLIP OS for more than 10 years. We (CLIP OS developers) wanted to upstream this new flag and the associated security features. Because CLIP OS is fully controlled (all applications are built and may be patched by ourselves), changing the kernel ABI (even if not desirable) is not a major issue. This is the reason why we were able to implement and maintained such non-upstream flag. The upstream process has the benefit to create discussions, but upstreaming also requires to deal with existing systems compatibility. CLIP OS relies on the Linux kernel, and the additional O_MAYEXEC flag (among other things) is, until now, a specificities of our distro, and we have the burden to check that it works and doesn't break for each system update.

This patch series brings some improvements to our original implementation, and more importantly enables other systems to progressively adopt this new feature. This is why this flag will only be handled by openat2(2) and is controlled by a sysctl, which weren't part of the original implementation because it wasn't require thanks to our total control of user space.

The O_MAYEXEC semantic is unchanged (according to the sysctl configuration), and it is highly unlikely that new flags will be added to the (old) open(2) and openat(2). This should then not be an issue to keep this specificity of CLIP OS 4. Anyway, none of these compatibility issues of a derivative kernel should concern upstream: it is part of the deal to implement new features without upstreaming them first. Moreover, a new CLIP OS 5 is on its way to replace the forth version.

O_MAYEXEC — explicitly opening files for execution

dvdeug — Fri, 15 May 2020 00:36:47 +0000

If it runs on DEC Ultrix, etc., it's well aware of the fact that functionality in different operating systems may have the same name and different semantics. Compatibility has a cost, and it seems too high to pay here for compatibility with an obscure system like CLIP OS and the few people who might have added compatibility with it.

O_MAYEXEC — explicitly opening files for execution

mjg59 — Thu, 14 May 2020 22:40:58 +0000

CLIP OS is a Linux derivative. If they choose to add new semantics without discussion with Linux upstream, you don't get to expect those semantics to be consistent. CLIP OS could have namespaced the flag to reduce the probability of conflict but didn't, so here we are.

> merely making people aware of the CLIP OS prior art and requesting to be compatible.

> adding it elsewhere MUST NOT change semantics!

Ok.

O_MAYEXEC — explicitly opening files for execution

mirabilos — Thu, 14 May 2020 22:36:02 +0000

Erm… please start brain before commenting.

This userspace uses O_MAYEXEC, which was defined by CLIP OS, if O_MAYEXEC is present, and using the CLIP OS semantics.

This userspace isn’t even natively developed on/for Linux, it’s just one of dozens of ports. It even runs on DEC Ultrix.

So, no, I don’t see why it’s the fault of this userspace if Linux were to decide to implement a functionality that already exists in another operating system, but with the same name but different semantics.

Also, this isn’t fault-assigning; merely making people aware of the CLIP OS prior art and requesting to be compatible.

O_MAYEXEC — explicitly opening files for execution

dvdeug — Thu, 14 May 2020 19:57:10 +0000

I might buy that argument for FreeBSD, though I also might buy that argument that FreeBSD used such a common name that we're not going to avoid it when doing something similar but slightly different. When you add support for obscure systems like CLIP OS, it's no more reasonable to expect that Linux will follow suit in the exact same way than it is to add support for a feature in C++2x and expect the final version of the standard to support it in the exact same way.

O_MAYEXEC — explicitly opening files for execution

mjg59 — Thu, 14 May 2020 17:21:25 +0000

Userspace that depends on the semantics of a patch that isn't in upstream doesn't get to complain if upstream ends up choosing different semantics.

O_MAYEXEC — explicitly opening files for execution

mina86 — Thu, 14 May 2020 16:28:16 +0000

Yes, sorry, a typo. I meant underscore, not a pipe.

O_MAYEXEC — explicitly opening files for execution

dkg — Thu, 14 May 2020 16:23:44 +0000

I'm pretty sure you mean to wrap the entire script in:

_() {
    […]
}
_

the trailing pipe doesn't make sense.

O_MAYEXEC — explicitly opening files for execution

mirabilos — Thu, 14 May 2020 16:06:07 +0000

Not exactly, sure, but if they use the same name *and* are aware of prior art, the semantics should be the same, as otherwise userspace is going to break ;-)

O_MAYEXEC — explicitly opening files for execution

mina86 — Thu, 14 May 2020 08:51:47 +0000

Time-of-check/time-to-use is why atomicity is required. Security checks without atomicity are pointless.

O_MAYEXEC — explicitly opening files for execution

mina86 — Thu, 14 May 2020 08:43:38 +0000

The one real issue with ‘curl | bash’ is an interrupted connection. If the script being downloaded isn’t written properly, this can lead to execution of corrupted script and e.g. ‘rm -rf /’ instead of ‘rm -rf /tmp/my-temp-file’.

For those wondering, the way to guard against that is to wrap the entire script with ‘_() { …; }; |’.

What's the fopen() equivalent?

dtlin — Thu, 14 May 2020 08:34:10 +0000

Not necessary,

fdopen(openat2(AT_FDCWD, pathname, O_RDONLY | O_MAYEXEC), "r")

should work fine.

What's the fopen() equivalent?

Karellen — Thu, 14 May 2020 08:21:33 +0000

Why would that be necessary?

fopen() is the C standard library, lowest-common-denominator function for opening files. It doesn't have many options, in order to be maximally portable. open()/openat() is more powerful, but specific to POSIX (and openat2() to Linux), and there are already a lot of open() flags that don't have equivalents in fopen(), like O_EXCL, O_CLOEXEC, O_NOATIME, etc...

In fact, C doesn't even have exec(), so wouldn't it be a bit odd to define a O_MAYEXEC flag for fopen()?

O_MAYEXEC — explicitly opening files for execution

dvdeug — Thu, 14 May 2020 02:09:15 +0000

It's a suggestion to be consistent with previous semantics, but minor operating systems implementing things do not bind major operating systems to do things the same way, and to do so would be pretty crippling on the ability to innovate.

O_MAYEXEC — explicitly opening files for execution

ianmcc — Wed, 13 May 2020 17:29:08 +0000

Its a little difficult to parse that quadruple negative statement. Is something of the form 'cat file | interpreter' an example of the interpreter reading a non-interactive stdin? I'd have thought this kind of thing was ubiquitous on unix systems.

What's the fopen() equivalent?

david.a.wheeler — Wed, 13 May 2020 14:34:55 +0000

A lot of systems use fopen(), not open2(). What's the letter equivalent in fopen()? That should be agreed-on soon so everyone can use the same one.

O_MAYEXEC — explicitly opening files for execution

mirabilos — Wed, 13 May 2020 12:46:26 +0000

(That is, passing it as flag to open(2), or’d with O_RDONLY, because that’s what CLIP OS documents.)

O_MAYEXEC — explicitly opening files for execution

mirabilos — Wed, 13 May 2020 12:41:53 +0000

There’s an O_MAYEXEC already in existence, from CLIP OS: https://lwn.net/Articles/768819/

I already support that in mksh, so adding it elsewhere MUST NOT change semantics!

O_MAYEXEC — explicitly opening files for execution

mst@redhat.com — Wed, 13 May 2020 10:54:52 +0000

The flag makes sense. Sysctl knob is weird
why not do it in a securoty module? Ideas?

O_MAYEXEC — explicitly opening files for execution

ballombe — Wed, 13 May 2020 09:18:04 +0000

What ? We do this all the time in HPC.

O_MAYEXEC — explicitly opening files for execution

kalvdans — Wed, 13 May 2020 05:59:17 +0000

There is already a system call for this single purpose: access(filename, X_OK). Passing it as a flag to open() brings atomicity, but to me none of the usecases discussed in the Linux mailing list or the PEP need atomicity.

O_MAYEXEC — explicitly opening files for execution

embe — Tue, 12 May 2020 22:52:43 +0000

From the patch series description:

Additional Python security improvements (e.g. a limited interpreter
withou -c, stdin piping of code) are on their way.

O_MAYEXEC — explicitly opening files for execution

edeloget — Tue, 12 May 2020 21:01:18 +0000

Honnestly, that's a feature that I'm going use -- I've been trying to find a way to close the loophole of scripts that can be executed from a noexec filesystem for a while, and I'm quite happy with it :)

Of course it's still possible to pipe a string to an interpreter but the change is still interesting to me.

O_MAYEXEC — explicitly opening files for execution

error27 — Tue, 12 May 2020 18:42:16 +0000

I think you're right that that's what will happen. But you can disable it with a sysctl until everything is fixed. It's just like SELinux and people will eventually get used to it.

O_MAYEXEC — explicitly opening files for execution

l0kod — Tue, 12 May 2020 16:37:44 +0000

As explained in the documentation patch, the ability to restrict code execution must be thought as a system-wide policy: https://lwn.net/ml/linux-kernel/20200505153156.925111-6-m...
As with other security policies, enforcing such execution prevention do not make sense on all system installations, especially developers' ones.

O_MAYEXEC is only one part of the solution. According to your threat model, using stdin (or other ways) to push code to interpreters may be legitimate or not. O_MAYEXEC doesn't help for this problem, but there is other solutions (which don't require kernel modification). You can get inspiration from CLIP OS 4: https://github.com/clipos-archive/clipos4_portage-overlay...

The difference between code and data is relative. According to your threat model, one way to draw a line is to identify which kind of input (Python, JavaScript, HTML, CSS…) can do system calls (which could lead to kernel attacks) or can have fine control of CPU instructions (which could lead to side channel attacks): https://lore.kernel.org/lkml/d1a81d06-7530-1f2b-858a-e42b...

O_MAYEXEC — explicitly opening files for execution

l0kod — Tue, 12 May 2020 16:10:26 +0000

General purpose distros will not enforce anything by default but will let sysadmins tune their system (according to its mount points and files). Only tailored security distros will embedded such security policy.

O_MAYEXEC — explicitly opening files for execution

matthias — Tue, 12 May 2020 15:56:03 +0000

This mechanism should prevent python from accidentially executing code from the data filesystem instead of the directory where you approved scripts are. It can step in if other measures have failed and an attacker tricked python to open the wrong script, e.g., because some user input on a web server was not properly checked/escaped. If an attacker is able to execute arbitrary shell commands like "cat abc | python" it is way too late. The chances are quite bad to stop an attacker at that point.

This mechanism is not meant to stop local users. If you have an interactive shell you can just start python and type any command that is inside abc. In many attack scenarios, the attacker has very little control over what commands can be executed and needs some vector to get arbitrary commands into the system. Not everyone, who can trick python to execute the wrong script (e.g., a script in some data directory) also has the ability to control the stdin of the python process.

O_MAYEXEC — explicitly opening files for execution

dskoll — Tue, 12 May 2020 13:49:37 +0000

The only way to detect "non-interactive" stdin is to check if it's a tty, and that's easily spoofed with a pseudoterminal.

O_MAYEXEC — explicitly opening files for execution

smurf — Tue, 12 May 2020 13:24:12 +0000

I don't think teaching interpreters to not execute non-interactive stdin is a bad idea. No sane system should require that.

O_MAYEXEC — explicitly opening files for execution

dskoll — Tue, 12 May 2020 11:59:31 +0000

For the latter case, you'd need a fcntl informing the system of your intent to execute stdin and it could do its checks. For the former case, I guess you'd have to fail the fcntl if stdin does not refer to a plain file. That would be a big and backwards-incompatible change.

O_MAYEXEC — explicitly opening files for execution

LiPo — Tue, 12 May 2020 10:47:26 +0000

Suppose that Python is updated. If I cannot do "python abc", what prevents me from doing "cat abc | python" or "python < abc"?

O_MAYEXEC — explicitly opening files for execution

dullfire — Tue, 12 May 2020 10:42:04 +0000

While the idea of improving security measures is commendable, I am not sure that this idea actually buys us a whole lot.
For example "echo 'print("Hello foobar")' |python" will still work, and as somebody else has already rightly pointed out: this can't be used to stop interpreters from using stdin (and in fact attempting to do so sounds like a terrible idea).
Furthermore, it sounds like this is attempting to create a link between kernel semantics (is the kernel allowed to create a process image out of this file), and pure user-land semantics (can any program, anywhere, use this file as flow control). If that's the case, does that mean all html, and js (that want to be executed/view locally rather than severed) potentially need to be marked as executable?

If we want to lock it down that badly, we probably also need to disable access to /proc/self. I'm pretty sure I could use a bash shell script to do some ROP in the very same shell to get the shell to MMAP some code as executable and then dd in w/e data I wanted.... now I have code execution. Seccomp could probably stop that (unless bash actually uses mmap, not sure).

My point is while the goals are laudable, I don't think this approach is a very well thought out way to attempt to tackle this problem.

O_MAYEXEC — explicitly opening files for execution

ballombe — Tue, 12 May 2020 09:41:56 +0000

Agreed. PyPi/NPM provide a false sense of security while being very convenient, which is a combination that leads to disasters.
curl | bash provide a correct sense of insecurity while being rather inconvenient. Much less likely to lead to a disaster.

O_MAYEXEC — explicitly opening files for execution

jezuch — Tue, 12 May 2020 05:59:18 +0000

Me wonders, what would happen if the Java VM was modified to use this flag, then some distribution flicked the switch and everyone was forced to chmod +x all their .jar files? ;)