4 ms·

Library relinking, mimmutable(2), xonly, along with other recent developments such as the removal of indirect syscall(2), make syscall pinning all the more inte

by brynet 3y ago

Library relinking, mimmutable(2), xonly, along with other recent developments such as the removal of indirect syscall(2), make syscall pinning all the more interesting, and raise the bar against attackers significantly. One can only hope that more will eventually find its way into Linux, like with how paid employees at Google have been spending the past ~6 months cloning mimmutable (which HN characters decried as "useless") to make mseal() for defending Chrome. https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b

saagarjha 3y ago
mimmutable, given a proper security model, doesn't seem useless. Lots of people have adopted something like this; Chrome is trying to bring it to Linux but Apple has been shipping a similar VM_FLAGS_PERMANENT for the last two years or so, which I believe even predates mimmutable making it to OpenBSD. In general, mitigations can raise the bar against attackers, but they don't have to. Determining whether it does can be pretty difficult, especially to those who come up with mitigations ;)
- brynet 3y ago
  > Lots of people have adopted something like this; Really? And how many systems have made any effort to use it, on OpenBSD most of a programs static address space is now automatically immutable (main program .text, ld.so .text, .bss, main stack, dymamically-loaded shared libraries, and dlopen()'d libraries mapped w/ RTLD_NODELETE. Nobody else have done the work on a complete operating system.
  - saagarjha 3y ago
    Question for you: why do you do this? "We made most of the address space immutable" is, by itself, not a useful property security-wise. What analysis did you do to arrive at it being necessary? I mean this as a genuine question but pose it in the context of what everyone else is doing. You're basically going "nobody else did this properly" because others did a different implementation. In other operating systems at least they go "oh we saw a chain that targeted xyz structure in this page and modified it so we are going to make sure it is really immutable". How did OpenBSD arrive at the conclusion that what other people are doing doesn't actually confer the full security benefit?

by brynet 3y ago

saagarjha 3y ago

mimmutable, given a proper security model, doesn't seem useless. Lots of people have adopted something like this; Chrome is trying to bring it to Linux but Apple has been shipping a similar VM_FLAGS_PERMANENT for the last two years or so, which I believe even predates mimmutable making it to OpenBSD. In general, mitigations can raise the bar against attackers, but they don't have to. Determining whether it does can be pretty difficult, especially to those who come up with mitigations ;)

brynet 3y ago
> Lots of people have adopted something like this; Really? And how many systems have made any effort to use it, on OpenBSD most of a programs static address space is now automatically immutable (main program .text, ld.so .text, .bss, main stack, dymamically-loaded shared libraries, and dlopen()'d libraries mapped w/ RTLD_NODELETE. Nobody else have done the work on a complete operating system.
- saagarjha 3y ago
  Question for you: why do you do this? "We made most of the address space immutable" is, by itself, not a useful property security-wise. What analysis did you do to arrive at it being necessary? I mean this as a genuine question but pose it in the context of what everyone else is doing. You're basically going "nobody else did this properly" because others did a different implementation. In other operating systems at least they go "oh we saw a chain that targeted xyz structure in this page and modified it so we are going to make sure it is really immutable". How did OpenBSD arrive at the conclusion that what other people are doing doesn't actually confer the full security benefit?