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

1–10 of 72 posts

Re: FreeBSD – a lesson in poor defaults

#4

Post by 0xcde4c3db »

> 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 avoid this by using mlock() [1]. Unfortunately, by default the ZFS ARC can grow beyond the limit for wired pages, which will make those mlock() calls start failing once the system has been up long enough [2].

[1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/mlock.html

[2] https://ximalas.info/2012/04/10/not-enough-room-for-wired-pa...

Re: FreeBSD – a lesson in poor defaults

#7

Post by stouset »

As an infosec guy having read some of the past discussions here — mostly about how infosec people are overzealous and don’t understand how disruptive these types of changes can be to existing installed bases — we do get it. The problem ends up being that improvements already take ages to work their way downstream, and not making them for compatibility reasons is a self-defeating prophecy. Those compatibility concerns will still exist next week, next month, and next year without actually working to address and reduce the problem. Often times they’re even worse as the installed base continues to grow and/or calcify around the existing setup.

The net result is that the compatibility argument, usually unintentionally, results in the status quo being kept for years. And when it already takes so long for these changes to make it out to users due to slow upgrade cycles, slow repackaging by downstream maintainers, slow uptake of new defaults, etc., with this same argument happening at each and every level… it often results in little to no progress over the span of years to common threats and pitfalls that are making people vulnerable today. That’s also why some of us try so hard to make sure developers get things right early on in their designs, since fixing it after the fact can be such an ordeal.

Of course, we understand the plight of maintainers not wanting to disrupt their users. It’s a difficult situation from both sides of the debate for sure. And also of course developing new features is more likely to make both users and developers happier than fixing security bugs is, at least in the short term. Just wanted to put the opposite perspective here as well since it felt underrepresented in previous discussions.

One thing to note, this isn’t necessarily indicative of my agreement with all of his analysis or belief that many of these are severe and need urgent fixing. This is more targeted at the meta-discussion around overzealous security people.

Re: FreeBSD – a lesson in poor defaults

#8

Post by vog »

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 SWAP, or no SWAP at all. The downsides are negligible compared to the upsides.

Re: FreeBSD – a lesson in poor defaults

#10

Post by loeg »

This was "Last updated 12/08/2017." That update does not include removing portions that are no longer true — instead they have published an update section at the very bottom.

Re: sendmail, check out the age of most of those CVEs (2006 or earlier). But also, see https://lists.freebsd.org/pipermail/freebsd-arch/2017-Decemb... .

Post reply on HN