5 ms·

The OpenBSD folks have a mentality of secure by default. Doing the best to encourage disk encryption upon install promotes that ideal.

by YPPH 4y ago

aspyct 4y ago
Yes, my point exactly. Disk encryption wasn't even part of the default install flow before. You had to go out of your way to find documentation, understand how to run it, find some more documentation, get "RTFM" replies on their IRC channel. Doesn't seem very secure by default to me.
- prmoustache 4y ago
  At least they gave you a refund.
  - aspyct 4y ago
    Lol, that's the default response when people complain about other people being rude and not having paid something. Look, I was just trying OpenBSD with an open mind, and I met people who were unhelpful. Even in the street if I asked someone for the time and he said "get a watch", it would be rude. I understand that they don't want to help. But do they need to be rude about it?
- nix23 4y ago
  >Doesn't seem very secure by default to me. If you don't understand a system it's by definition not secure, keep your hands away or start learning your stuff, or at least don't call it secure (the big word that includes many different meanings)
- Zurrrrr 4y ago
  "secure by default" by OBSD basically just means everything disabled by default. Can't hack anything if nothing is running, right? Only issue is it's not that useable either.
  - camgunz 4y ago
    You've made a few comments implying that if OpenBSD ran some common services by default attackers would get remote root and nothing would stop them. But their services have a pretty good track record: - OpenSMTPd: 2 remote holes in 10 years - OpenSSH: 1 remote hole in 10 years - httpd: No remote vulns - relayd: No remote vulns What are you looking at that makes you confident that if OpenBSD ran these by default (which I think is a bad idea in general) they'd have a significantly worse security history?
    - Zurrrrr 4y ago
      I don't mean to imply that if OpenBSD ran those specific services by default that it would be much worse. My point is that: a) Generally for a server people are running some kind of services, and that's going to include third party software. Not always, but often, and that software is not audited by OBSD team. Even say adding a module to httpd may allow for remote compromise and b) That the tools OpenBSD provides for dealing with an attacker who has managed to gain remote access are insufficient compared to what is available, and especially insufficient for an OS that claims to be focused on security.
      - camgunz 4y ago
        > Generally for a server people are running some kind of services, and that's going to include third party software. Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux? I think that's pretty wrong. Running services in a chroot with pledge gives you a lot of security. And the other security features [0] (empirically) help reduce the occurrence of remote vulns overall with far less complexity than SELinux (which also totally weirds your system). [0]: https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html
        Zurrrrr 4y ago
        > Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux? You sure put in a lot of effort to misconstruing me there. So many people in this thread who are responding emotionally and without the knowledge to really have a proper discussion. Instead of trying to defend pledge, maybe do some more reading on SELinux and understand just how fundamentally different the approaches are, and why pledge just can't compare.
- yjftsjthsd-h 4y ago
  I don't know man, if you weren't going to read the documentation then what are the odds that the system was ever going to be secure for you?
- 2b3a51 4y ago
  Has been in the 'disk setup' part of the FAQ for quite a long time I think. Do you have special requirements e.g. external key disk or something unusual?
quesera 4y ago
It works both ways. The OpenBSD developers know that their users take security seriously, over convenience and just-works installers. So it's a safe bet that OpenBSD users will take the few extra (well-documented) manual steps to encrypt their storage devices, leaving the developers to focus on things that are not easy for users to do for themselves. Adding the convenience to the interactive installer is clearly a good thing, but it would not be at the tippy-top of the priority list if you have limited funding and developer time.
- YPPH 4y ago
  I mean, is that not like saying that a user will RTFM and disable all unnecessary services after their install? The OpenBSD mentality is the opposite - they will sacrifice convenience and disable all unnecessary services by default, in order to make the system as secure as possible, and you can go RTFM and knowingly increase your risk if you choose to. That mentality would suggest, I think, disk encryption should be opt-out on the install. Of course, the first step to getting there is an opt-in system.
  - quesera 4y ago
    It is, yes. It definitely works both ways. In this case (disk encryption) the process is simple, but the data collection and then things like back/fwd, changes, accept etc.. makes it more complicated than a simple boolean/checkbox. So the compromise was "bounce to the docs for this one", until this new improvement was added.

The OpenBSD folks have a mentality of secure by default. Doing the best to encourage disk encryption upon install promotes that ideal.

by YPPH 4y ago

The OpenBSD folks have a mentality of secure by default. Doing the best to encourage disk encryption upon install promotes that ideal.

aspyct 4y ago

Yes, my point exactly. Disk encryption wasn't even part of the default install flow before. You had to go out of your way to find documentation, understand how to run it, find some more documentation, get "RTFM" replies on their IRC channel. Doesn't seem very secure by default to me.

prmoustache 4y ago
At least they gave you a refund.
- aspyct 4y ago
  Lol, that's the default response when people complain about other people being rude and not having paid something. Look, I was just trying OpenBSD with an open mind, and I met people who were unhelpful. Even in the street if I asked someone for the time and he said "get a watch", it would be rude. I understand that they don't want to help. But do they need to be rude about it?
nix23 4y ago
>Doesn't seem very secure by default to me. If you don't understand a system it's by definition not secure, keep your hands away or start learning your stuff, or at least don't call it secure (the big word that includes many different meanings)
Zurrrrr 4y ago
"secure by default" by OBSD basically just means everything disabled by default. Can't hack anything if nothing is running, right? Only issue is it's not that useable either.
- camgunz 4y ago
  You've made a few comments implying that if OpenBSD ran some common services by default attackers would get remote root and nothing would stop them. But their services have a pretty good track record: - OpenSMTPd: 2 remote holes in 10 years - OpenSSH: 1 remote hole in 10 years - httpd: No remote vulns - relayd: No remote vulns What are you looking at that makes you confident that if OpenBSD ran these by default (which I think is a bad idea in general) they'd have a significantly worse security history?
  - Zurrrrr 4y ago
    I don't mean to imply that if OpenBSD ran those specific services by default that it would be much worse. My point is that: a) Generally for a server people are running some kind of services, and that's going to include third party software. Not always, but often, and that software is not audited by OBSD team. Even say adding a module to httpd may allow for remote compromise and b) That the tools OpenBSD provides for dealing with an attacker who has managed to gain remote access are insufficient compared to what is available, and especially insufficient for an OS that claims to be focused on security.
    - camgunz 4y ago
      > Generally for a server people are running some kind of services, and that's going to include third party software. Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux? I think that's pretty wrong. Running services in a chroot with pledge gives you a lot of security. And the other security features [0] (empirically) help reduce the occurrence of remote vulns overall with far less complexity than SELinux (which also totally weirds your system). [0]: https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html
      - Zurrrrr 4y ago
        > Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux? You sure put in a lot of effort to misconstruing me there. So many people in this thread who are responding emotionally and without the knowledge to really have a proper discussion. Instead of trying to defend pledge, maybe do some more reading on SELinux and understand just how fundamentally different the approaches are, and why pledge just can't compare.
yjftsjthsd-h 4y ago
I don't know man, if you weren't going to read the documentation then what are the odds that the system was ever going to be secure for you?
2b3a51 4y ago
Has been in the 'disk setup' part of the FAQ for quite a long time I think. Do you have special requirements e.g. external key disk or something unusual?

quesera 4y ago

It works both ways. The OpenBSD developers know that their users take security seriously, over convenience and just-works installers. So it's a safe bet that OpenBSD users will take the few extra (well-documented) manual steps to encrypt their storage devices, leaving the developers to focus on things that are not easy for users to do for themselves. Adding the convenience to the interactive installer is clearly a good thing, but it would not be at the tippy-top of the priority list if you have limited funding and developer time.

YPPH 4y ago
I mean, is that not like saying that a user will RTFM and disable all unnecessary services after their install? The OpenBSD mentality is the opposite - they will sacrifice convenience and disable all unnecessary services by default, in order to make the system as secure as possible, and you can go RTFM and knowingly increase your risk if you choose to. That mentality would suggest, I think, disk encryption should be opt-out on the install. Of course, the first step to getting there is an opt-in system.
- quesera 4y ago
  It is, yes. It definitely works both ways. In this case (disk encryption) the process is simple, but the data collection and then things like back/fwd, changes, accept etc.. makes it more complicated than a simple boolean/checkbox. So the compromise was "bounce to the docs for this one", until this new improvement was added.