5 ms·

> I don't absolutely, fully buy into OpenBSD is "very secure". Some of its mitigations are good but many do feel a bit arbitrary. Can you explain how "some mi

by zvmaz 3y ago

> I don't absolutely, fully buy into OpenBSD is "very secure". Some of its mitigations are good but many do feel a bit arbitrary. Can you explain how "some mitigations feel arbitrary"? A specific example for us to ponder on?

sidkshatriya 3y ago
> A specific example for us to ponder on? Let me answer that first in a general way. Every security measure needs to have a threat model. A model is necessary because one could come up with all kinds of security measures that while boosting security in some (possibly even minor) way might lead to drastically reduced performance/useability. Using OpenBSD on a day to day basis I realized it was very slow. I don't know how much of a slowness of OpenBSD is due to some of these security measures with unbalanced tradeoffs or how much it was just due to a lack developer manpower to improve performance. Mitigations. One of the OpenBSD mitigations is to allowing syscalls only from OpenBSD libc and then only only certain portions of libc. That is something I'm not a fan off. I feel it (a) makes OpenBSD libc special and prevents competing libc-s from coming up (b) reduces freedom in userspace programs -- they have to go via blessed userspace piece of code. I think OpenBSD should continue locking down the userspace/kernel interface from a security perspective but not ban syscalls from locations other than libc. I'm not sure how much extra security it buys you compared to the reduced overall flexibility of the system. The interface to concentrate on security is userspace/kernel and not userspace/userspace-libc IMHO. Lastly, I find that OpenBSD invests a lot of time and energy in mitigations. But the biggest problem of all is that the C/C++ based kernel and system inherently are very unsafe. I would have expected a greater emphasis in OpenBSD to move towards safer languages at least in userspace if not the kernel. But OpenBSD resolutely sticks to C/C++. Linux OTOH is a bit more open -- Rust is small now but give it a decade or so and I expect a lot of drivers will be written in Rust -- an inherently safer choice.
- toyg 3y ago
  I don't necessarily agree on the libc thing but I do agree that OpenBSD have missed the boat on Rust. It should be the natural platform for it, and sadly it's anything but. The project feels very fossilized on various somewhat-outdated views. It probably won't change until there is a significant change in leadership, something that is always difficult and traumatic for BSD projects.
  - greyw 3y ago
    Speaking of fossilized, OpenBSD still uses cvs for version control supposedly because it works well enough. Cvs "works", but then again I haven't yet seen a worse version control system.
    - toyg 3y ago
      It's one of those things... Their longtime developers, by now, know it so well that switching is going to hit their productivity; and it's been audited and hardened for so long that, for a project whose reason of being is security, abandoning it would incur serious risks. Like with binary patches, moving from CVS is something that they will never do until someone "inside" decides that it's time to do it.

by zvmaz 3y ago

sidkshatriya 3y ago

> A specific example for us to ponder on? Let me answer that first in a general way. Every security measure needs to have a threat model. A model is necessary because one could come up with all kinds of security measures that while boosting security in some (possibly even minor) way might lead to drastically reduced performance/useability. Using OpenBSD on a day to day basis I realized it was very slow. I don't know how much of a slowness of OpenBSD is due to some of these security measures with unbalanced tradeoffs or how much it was just due to a lack developer manpower to improve performance. Mitigations. One of the OpenBSD mitigations is to allowing syscalls only from OpenBSD libc and then only only certain portions of libc. That is something I'm not a fan off. I feel it (a) makes OpenBSD libc special and prevents competing libc-s from coming up (b) reduces freedom in userspace programs -- they have to go via blessed userspace piece of code. I think OpenBSD should continue locking down the userspace/kernel interface from a security perspective but not ban syscalls from locations other than libc. I'm not sure how much extra security it buys you compared to the reduced overall flexibility of the system. The interface to concentrate on security is userspace/kernel and not userspace/userspace-libc IMHO. Lastly, I find that OpenBSD invests a lot of time and energy in mitigations. But the biggest problem of all is that the C/C++ based kernel and system inherently are very unsafe. I would have expected a greater emphasis in OpenBSD to move towards safer languages at least in userspace if not the kernel. But OpenBSD resolutely sticks to C/C++. Linux OTOH is a bit more open -- Rust is small now but give it a decade or so and I expect a lot of drivers will be written in Rust -- an inherently safer choice.

toyg 3y ago
I don't necessarily agree on the libc thing but I do agree that OpenBSD have missed the boat on Rust. It should be the natural platform for it, and sadly it's anything but. The project feels very fossilized on various somewhat-outdated views. It probably won't change until there is a significant change in leadership, something that is always difficult and traumatic for BSD projects.
- greyw 3y ago
  Speaking of fossilized, OpenBSD still uses cvs for version control supposedly because it works well enough. Cvs "works", but then again I haven't yet seen a worse version control system.
  - toyg 3y ago
    It's one of those things... Their longtime developers, by now, know it so well that switching is going to hit their productivity; and it's been audited and hardened for so long that, for a project whose reason of being is security, abandoning it would incur serious risks. Like with binary patches, moving from CVS is something that they will never do until someone "inside" decides that it's time to do it.