On 06/09/2019 22:06, Andy Lutomirski wrote: > > >> 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. This is the purpose of this patch series. It doesn't make sense to add memory restrictions nor constrain fexecve and such. > > - 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. > -- Mickaël Salaün Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@xxxxxxxxxxxxx. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@xxxxxxxxxxxxx. If you have received this message in error, we thank you for informing the sender and destroying the message.
