On Sep 6, 2019, at 12:43 PM, Jeff Layton [off-list ref] wrote:

quoted

On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:

quoted

On 2019-09-06, Jeff Layton [off-list ref] wrote:

quoted

On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:

quoted

On 06/09/2019 17:56, Florian Weimer wrote:
Let's assume I want to add support for this to the glibc dynamic loader,
while still being able to run on older kernels.

Is it safe to try the open call first, with O_MAYEXEC, and if that fails
with EINVAL, try again without O_MAYEXEC?

The kernel ignore unknown open(2) flags, so yes, it is safe even for
older kernel to use O_MAYEXEC.

Well...maybe. What about existing programs that are sending down bogus
open flags? Once you turn this on, they may break...or provide a way to
circumvent the protections this gives.

It should be noted that this has been a valid concern for every new O_*
flag introduced (and yet we still introduced new flags, despite the
concern) -- though to be fair, O_TMPFILE actually does have a
work-around with the O_DIRECTORY mask setup.

The openat2() set adds O_EMPTYPATH -- though in fairness it's also
backwards compatible because empty path strings have always given ENOENT
(or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.

quoted

Maybe this should be a new flag that is only usable in the new openat2()
syscall that's still under discussion? That syscall will enforce that
all flags are recognized. You presumably wouldn't need the sysctl if you
went that route too.

I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
it, since I'd heard about this work through the grape-vine).

I rather like the idea of having openat2 fds be non-executable by
default, and having userland request it specifically via O_MAYEXEC (or
some similar openat2 flag) if it's needed. Then you could add an
UPGRADE_EXEC flag instead?

That seems like something reasonable to do with a brand new API, and
might be very helpful for preventing certain classes of attacks.

There are at least four concepts of executability here:

- Just check the file mode and any other relevant permissions. Return a normal fd.  Makes sense for script interpreters, perhaps.

- Make the fd fexecve-able.

- Make the resulting fd mappable PROT_EXEC.

- Make the resulting fd upgradable.

I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.