27 ms·

>Lots of things already `dlopen`, lots of things already obscure their true dependencies by doing so. This RFC only provides a new section for those things to d

>Lots of things already `dlopen`, lots of things already obscure their true dependencies by doing so. This RFC only provides a new section for those things to declare their dependencies without making the OS responsible for loading them. The OS should be responsible for opening dependencies. Otherwise you get an unaccountable mess. The ELF note shit is just giving users a false sense of security. >Anyone is welcome to make contributions to Linux or the surrounding ecosystem. Ha! This certainly isn't true. Even if it was, the source of "contributions" deserves scrutiny.

striking 3y ago
Assuming you're actually proposing that every possible library is listed in the ELF and loaded before the executable starts by the OS' loader, I would encourage you to try writing an AppArmor or seccomp profile that bans `dlopen` and see how many of your favorite applications still run. This is a completely unserious take that continues to misread the motivations of the RFC (it's not about security) and couldn't even be applied even to just the core of most actually used Linux userlands without an absurd amount of work (think of PAM modules and friends). Also, have I really misspoken? I was under the impression that many corporations with interests in proprietary software (including Microsoft) are regular contributors to the Linux kernel and ecosystem, but if I'm wrong I'd love to know the details.
- wakawaka28 3y ago
  >it's not about security The comments here suggest otherwise. It certainly can't provide a security function. >Assuming you're actually proposing that every possible library is listed in the ELF and loaded before the executable starts by the OS' loader, I didn't propose that but certainly the ability to load and execute code from anywhere is a vulnerability waiting to happen. Not being able to accurately enumerate dependencies is also an issue. If the OS was solely responsible for locating and loading dependencies, you could analyze any executable in isolation and get a definitive list of dependencies. >I would encourage you to try writing an AppArmor or seccomp profile that bans `dlopen` and see how many of your favorite applications still run. Just because it is that way now doesn't mean it needs to be. >Also, have I really misspoken? I was under the impression that many corporations with interests in proprietary software (including Microsoft) are regular contributors to the Linux kernel and ecosystem, but if I'm wrong I'd love to know the details. They do make contributions. But large corporations aren't "anyone" and their contributions are not unquestionable. They do have their own interests which are in conflict with the broader open-source ecosystem.
saurik 3y ago
At least on Linux and macOS, the "OS" never was responsible for this and I at least do not believe that it should become responsible for this; the kernel merely parses the header to see if it lists an "interpreter" and, if it does (as dynamic executables do), it loads that one binary (it might also load the original binary and pass its address as an argument to the interpreter). The interpreter is usually going to be something like /lib/ld.so, and is provided by the C standard library you linked against. You might have multiple copies that work very differently, and a new programming language can implement one that is nothing like the one from glibc or adds new features, etc. This program then parses the executable and does the moral equivalent of a dlopen on all of the dependencies. That said, I do agree that doing this in "notes" is dumb, and if they need some new feature of ELF like "alternatives" they should at least be coordinating this with glibc if not deferring the spec entirely to them. Hell: given that they previously were actually linking these things, I don't understand why a lazy loaded weak symbol wouldn't work. Does ELF not support those somehow? I thought it did. I don't think systemd is at all the best project to be trying to think through this stuff as they are always much happier adding a new complex mechanism when existing ones would work fine. If ELF is currently missing lazy loading, they should work with glibc to add that feature correctly, not try to end-to-end it through the notes field :/.
- Arnavion 3y ago
  To your last point, doing it without involving glibc does have the advantage that it'll also work with musl, instead of starting yet another flamewar about missing non-standard features in musl.
- wakawaka28 3y ago
  The whole ELF interpreter thing is a security hole as far as I'm concerned. I'm not an expert on it but as far as I know, the existence of ELF interpreters seems to make it impossible to get a definitive list of dependencies.

striking 3y ago

Assuming you're actually proposing that every possible library is listed in the ELF and loaded before the executable starts by the OS' loader, I would encourage you to try writing an AppArmor or seccomp profile that bans `dlopen` and see how many of your favorite applications still run. This is a completely unserious take that continues to misread the motivations of the RFC (it's not about security) and couldn't even be applied even to just the core of most actually used Linux userlands without an absurd amount of work (think of PAM modules and friends). Also, have I really misspoken? I was under the impression that many corporations with interests in proprietary software (including Microsoft) are regular contributors to the Linux kernel and ecosystem, but if I'm wrong I'd love to know the details.

wakawaka28 3y ago
>it's not about security The comments here suggest otherwise. It certainly can't provide a security function. >Assuming you're actually proposing that every possible library is listed in the ELF and loaded before the executable starts by the OS' loader, I didn't propose that but certainly the ability to load and execute code from anywhere is a vulnerability waiting to happen. Not being able to accurately enumerate dependencies is also an issue. If the OS was solely responsible for locating and loading dependencies, you could analyze any executable in isolation and get a definitive list of dependencies. >I would encourage you to try writing an AppArmor or seccomp profile that bans `dlopen` and see how many of your favorite applications still run. Just because it is that way now doesn't mean it needs to be. >Also, have I really misspoken? I was under the impression that many corporations with interests in proprietary software (including Microsoft) are regular contributors to the Linux kernel and ecosystem, but if I'm wrong I'd love to know the details. They do make contributions. But large corporations aren't "anyone" and their contributions are not unquestionable. They do have their own interests which are in conflict with the broader open-source ecosystem.

saurik 3y ago

At least on Linux and macOS, the "OS" never was responsible for this and I at least do not believe that it should become responsible for this; the kernel merely parses the header to see if it lists an "interpreter" and, if it does (as dynamic executables do), it loads that one binary (it might also load the original binary and pass its address as an argument to the interpreter). The interpreter is usually going to be something like /lib/ld.so, and is provided by the C standard library you linked against. You might have multiple copies that work very differently, and a new programming language can implement one that is nothing like the one from glibc or adds new features, etc. This program then parses the executable and does the moral equivalent of a dlopen on all of the dependencies. That said, I do agree that doing this in "notes" is dumb, and if they need some new feature of ELF like "alternatives" they should at least be coordinating this with glibc if not deferring the spec entirely to them. Hell: given that they previously were actually linking these things, I don't understand why a lazy loaded weak symbol wouldn't work. Does ELF not support those somehow? I thought it did. I don't think systemd is at all the best project to be trying to think through this stuff as they are always much happier adding a new complex mechanism when existing ones would work fine. If ELF is currently missing lazy loading, they should work with glibc to add that feature correctly, not try to end-to-end it through the notes field :/.

Arnavion 3y ago
To your last point, doing it without involving glibc does have the advantage that it'll also work with musl, instead of starting yet another flamewar about missing non-standard features in musl.
wakawaka28 3y ago
The whole ELF interpreter thing is a security hole as far as I'm concerned. I'm not an expert on it but as far as I know, the existence of ELF interpreters seems to make it impossible to get a definitive list of dependencies.