Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FreeBSD – a lesson in poor defaults

vez.mrsk.me

Post reply on HN
Print view View original

31–40 of 72 posts

Re: FreeBSD – a lesson in poor defaults

#31

Post by tachion »

While you're here, have you donated[0][1] yet? :) You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation and Nitendo Switch, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everything else on OpenSSH. ;)

So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps the foundations keep their non-profit status. Also, you CAN be the change, if you specify what you'd like your donation to be used for (like more secure defaults for the OS).

[0] https://www.freebsdfoundation.org/donate/

[1] https://www.openbsd.org/donations.html

Re: FreeBSD – a lesson in poor defaults

#32

Post by tachion »

oscargrouch wrote: post #9
vog wrote: post #5

I wonder how this compares to other unix systems, such as OpenBSD or various Linux Distros.

HardenedBSD ( https://hardenedbsd.org ) also. Which is a recent fork of FreeBSD that has a focus on security.

Unfortunately, HardenedBSD is nothing more but a PR campaign from a one person who feels rejected due to poor code quality and bad reviews from FreeBSD developers who expect a bit more than just throwing random patches around and saying 'here, I fixed all these security problems with three lines of code'. I would recommend taking HardenedBSD and its announcements with a huge portion of salt.

Re: FreeBSD – a lesson in poor defaults

#33

Post by tachion »

floatboth wrote: post #28
marmaduke wrote: post #13

As someone looking to move a cluster from ancient Debian, I was looking at either CentOS or FreeBSD but this looks not so nice..

Honestly, most of the concerns are rather superficial. You might want to try HardenedBSD instead of regular FreeBSD though, to get all the exploit mitigation stuff.

Don't do that. HardenedBSD is rather a one man project, who's patches have been reviewed and rejected by FreeBSD developers due to bad quality, poor design and lack of cooperation in bringing them to FreeBSD expected standards. It seems like a PR campaign from people who can write some C, but don't have much credibility in writing secure operating systems or production ready code. Beside the quality of the proposed solutions, there was nothing in the FreeBSD project stopping the code from being accepted. Wether the bad ASLR implementation or no implementation is worse, it's up to you to decide, but I'll vote for quality first.

Re: FreeBSD – a lesson in poor defaults

#34

Post by tachion »

A lot of these has been already addressed by a security menu in the FreeBSD installer, since settings and/or mitigations for mentioned issues have been possible in FreeBSD but have not been enabled by default due to POLA (project's rule of Priciple Of Least Astonishment) in order to prevent users expecting some behaviour to be surprised by changes. Those who knew about these could always enable those, and those who didn't now have option to do it via the default installer.

Re: FreeBSD – a lesson in poor defaults

#35

Post by X86BSD »

tachion wrote: post #33
floatboth wrote: post #28

Earlier quoted context omitted.

Honestly, most of the concerns are rather superficial. You might want to try HardenedBSD instead of regular FreeBSD though, to get all the exploit mitigation stuff.

Don't do that. HardenedBSD is rather a one man project, who's patches have been reviewed and rejected by FreeBSD developers due to bad quality, poor design and lack of cooperation in bringing them to FreeBSD expected standards. It seems like a PR campaign from people who can write some C, but don't have much credibility in writing secure operating systems or production ready code. Beside the quality of the proposed s…

I could be wrong but I was under the impression certain sec folks objected to a lot of his patches because they just are not sold on if ASLR really adds any benefit. Or any benefit vs the complexity it adds. Correct me if I’m wrong. I know Theo has bought into it. I just recall in FreeBSD it wasn’t accepted if it really fixes anything.

Re: FreeBSD – a lesson in poor defaults

#36

Post by na85 »

tachion wrote: post #31

While you're here, have you donated[0][1] yet? :) You may or may not be aware, but FreeBSD runs your movies on Netflix, your games on PlayStation and Nitendo Switch, your files on FreeNAS and ZFS, your friends on WhatsApp and OpenBSD runs everything else on OpenSSH. ;) So, you may or may not know that, but you need FreeBSD and OpenBSD and they also need you! Every cent counts and so does every contributor, that helps…

Seems to me that Netflix, Sony, et al should be paying FreeBSD, not the users. Why would I subsidize FreeBSD so that mega corps can leech off the hard work of volunteers, and by extension leech off my donation?

Re: FreeBSD – a lesson in poor defaults

#38

Post by jemsa »

tachion wrote: post #32
oscargrouch wrote: post #9

Earlier quoted context omitted.

HardenedBSD ( https://hardenedbsd.org ) also. Which is a recent fork of FreeBSD that has a focus on security.

Unfortunately, HardenedBSD is nothing more but a PR campaign from a one person who feels rejected due to poor code quality and bad reviews from FreeBSD developers who expect a bit more than just throwing random patches around and saying 'here, I fixed all these security problems with three lines of code'. I would recommend taking HardenedBSD and its announcements with a huge portion of salt.

The funny part is that FreeBSD has had years to even implement anything as simple as ASLR but it didn't and instead starting to reject other peoples code. What HardenedBSD did is basically following the PaX model which has been documented for a long time[1]. It seems like FreeBSD is just lacking any developers willing to deal with these security features or let alone upstream it because its usually a pain in the ass to upstream stuff like this just look how Linux is having a hard time implementing even basic stuff from grsecurity. Exploit mitigations are not for fixing those security problems it is to make it harder to exploit certain vulnerabilities.

1: https://pax.grsecurity.net/docs/index.html

Re: FreeBSD – a lesson in poor defaults

#39

Post by drvdevd »

floatboth wrote: post #29
alien_ wrote: post #26

Earlier quoted context omitted.

Most new drives can do encryption in hardware with zero performance penalty using either the ATA password or Opal for NVMe. For those doing software/CPU encryption on the swap, or any other partition for the matter is simply wasteful and often slower.

Isn't on-drive encryption considered untrustworthy?

now i’m curious if anyone has tried to write their own encryption routines to any common hard drive firmware stacks

Re: FreeBSD – a lesson in poor defaults

#40

Post by jemsa »

tachion wrote: post #33
floatboth wrote: post #28

Earlier quoted context omitted.

Honestly, most of the concerns are rather superficial. You might want to try HardenedBSD instead of regular FreeBSD though, to get all the exploit mitigation stuff.

Don't do that. HardenedBSD is rather a one man project, who's patches have been reviewed and rejected by FreeBSD developers due to bad quality, poor design and lack of cooperation in bringing them to FreeBSD expected standards. It seems like a PR campaign from people who can write some C, but don't have much credibility in writing secure operating systems or production ready code. Beside the quality of the proposed s…

Yet FreeBSD hasn't done a single thing to improve the current state of exploit mitigations. It doesn't matter how many people are writing code, grsecurity is mainly Spender & pipacs aka PaXTeam yet 14 Linux developers couldn't spot the vulnerabilities they've created by copy pasting and editing code from grsecrutiy. You can't really blame others for trying while FreeBSD hasn't tried a single thing yet.
Post reply on HN