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

51–60 of 72 posts

Re: FreeBSD – a lesson in poor defaults

#51

Post by na85 »

boomboomsubban wrote: post #48
na85 wrote: post #44

Earlier quoted context omitted.

Obviously these hugely profitable companies don't pay enough. Otherwise I should not need to donate.

Obviously Windows should be free, with all the huge companies that use that. The logic makes no sense.

I'll try to explain my reasoning, then.

If Netflix and other very profitable companies are, as I'm told, contributing in both code and money to FreeBSD, and if I'm also being asked to donate, then the contributions from said corporations are obviously not enough to cover the costs of FreeBSD development.

Since I pay for Netflix, why should I double-pay by donating to FreeBSD? Seems to me that Netflix should be digging a little deeper into their pockets.

I don't understand your point re: Windows. If companies are paying for Windows, then Microsoft is receiving a payment which they have presumably set at a level they deem sufficient to support continuing development of Windows and other projects. I see no parallel to my point about FreeBSD other than the fact that both are operating systems.

Re: FreeBSD – a lesson in poor defaults

#52

Post by kingofhdds »

vog wrote: post #8
0xcde4c3db wrote: post #4

> I think swap should always be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I know has run hexdump on his swap partition and found PGP private keys in plain view. Your SSH key might be password-protected on disk, but it could end up in swap sooner or later... with no password needed. GnuPG and a few other security-conscious programs try to…

Moreover, you have stuff like password managers going though the clipboard. Relying on all tools correctly identifying their sensitive datasets and protecting them though mlock() is doomed to fail. If anything, a proper security concept should whitelist insensitive datasets, instead of blacklisting sensitive datasets. I don't get why any modern OS would use unencrypted SWAP. The default should be either encrypted SWA…

To tilt defaults to a safer side is usually (though, not always) good, if it's meant to be out-of-the-box system. Definitely, not the case here as bare-bones FreeBSD is essentially a platform for building a user's own solution for own needs. Not making too much assumptions about what they are is actually very rational for FBSD devs. I know my goal better, I know which choices/compromises I want to make.

Re: FreeBSD – a lesson in poor defaults

#53

Post by na85 »

kingofhdds wrote: post #45
0xcde4c3db wrote: post #4

> I think swap should always be encrypted. FreeBSD developers disagree. It's surprising just how much private data in memory gets written to disk. Someone I know has run hexdump on his swap partition and found PGP private keys in plain view. Your SSH key might be password-protected on disk, but it could end up in swap sooner or later... with no password needed. GnuPG and a few other security-conscious programs try to…

FreeBSD is a tune-it-yourself OS. You think your swap should be encrypted? Fine, append ".eli" to the name of your swap GEOM (partition, slice, whatever) in fstab, and you're done. Some may not require this at all, because FreeBSD may be used in a lot of different situations. Your needs - your choice.

The submission in question is about defaults, not about choice.

Re: FreeBSD – a lesson in poor defaults

#54

Post by ahh »

wolf550e wrote: post #17
ilammy wrote: post #16

Earlier quoted context omitted.

> encrypted SWAP When I was setting up dm-crypt for my Linux dev box at work I opted for using an encrypted swap as it really made sense: why keep on-disk stuff encrypted if swapped memory is in plain sight. It turned out to be a somewhat bad decision, because when the system did run out of memory (thank you, Firefox and Skype) and began swapping, the whole box just freezes as the kernel was too busy encrypting more…

I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.

I'm uncertain if it's safe to use AESENC and friends in kernel mode in Freebsd. A number of kernels can't safely use e.g. FPU registers in-kernel and aesni operates exclusively on SSE state.

Re: FreeBSD – a lesson in poor defaults

#55

Post by adrianN »

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?

Depends on your threat model. If you want to protect your data when your laptop is stolen, on-drive encryption is probably more than sufficient.

Re: FreeBSD – a lesson in poor defaults

#56

Post by loeg »

ahh wrote: post #54
wolf550e wrote: post #17

Earlier quoted context omitted.

I don't doubt your story, but modern CPUs can perform AES-GCM at gigabytes per second per core (5GB/sec on my laptop). Disk encryption is a different block cipher mode, but it shouldn't be much slower. So if implemented correctly, encrypted swap should not slow you down vs unencrypted swap. If in your setup encrypted swap is much slower than unencrypted swap, it's a bug in the kernel crypto and it should be fixed.

I'm uncertain if it's safe to use AESENC and friends in kernel mode in Freebsd. A number of kernels can't safely use e.g. FPU registers in-kernel and aesni operates exclusively on SSE state.

It's safe. The FreeBSD kernel is capable of preserving user FPU state when kernel threads (e.g., aesni(4)) need to use FPU registers.

Re: FreeBSD – a lesson in poor defaults

#57

Post by tachion »

jemsa wrote: post #38
tachion wrote: post #32

Earlier quoted context omitted.

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…

The funny part is that even amongst top security researchers there doesn't seem to be an agreement over the fact if ASLR is worth anything, as it was proved to be breakable in no time. And it seems like grsecurity code suffers the same problems as the code from HardenedBSD, that is the quality matching the respective project's standards.

Re: FreeBSD – a lesson in poor defaults

#58

Post by tachion »

jemsa wrote: post #40
tachion wrote: post #33

Earlier quoted context omitted.

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.

No one, at least not me, is blaming him for trying. But he is to be blamed for sending a poorly written and badly designed patch, unwilling to work on it until it meets the quality of the FreeBSD project and then 'forking' FreeBSD, applying these widely criticised patches and making a social campaign of "they don't want to fix security" instead of "they don't want to introduce bad code" what would be much closer to the truth.

Re: FreeBSD – a lesson in poor defaults

#59

Post by tachion »

na85 wrote: post #36
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?

You're not supposed to do that so that the mega corps could do that. You're supposed to do that so that _anyone_ could do that and benefit from the open source code that's best suited for running a business, even if your idea of running a business and using open source is to not share anything back.

Re: FreeBSD – a lesson in poor defaults

#60

Post by tachion »

Neeek wrote: post #49
boomboomsubban wrote: post #48

Earlier quoted context omitted.

Obviously Windows should be free, with all the huge companies that use that. The logic makes no sense.

It makes perfect sense if you don't personally own or use Windows. I don't pay Microsoft again to play TitanFall just because their servers are hosted on Azure. I understand we all probably use tools everyday that can be attributed to these projects and I don't mean to imply that you shouldn't give them money. Just that the Netflix/WhatsApp comments seem a little disingenuous. That shouldn't be in the "reasons you ne…

You might one day want to run a startup or a project and then you could just do it on FreeBSD in any way you like, given the permissive license and this is exactly the reason why you need BSD, not only because Netflix or WhatsApp uses them to serve you the service.
Post reply on HN