> On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote: >>> On 2019-09-06, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote: >>>>> 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. >> >>> 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.
