FreeBSD – a lesson in poor defaults • Hacker News Board

iomotoko wrote: post #3

Been here more than once, for past comments see 469 days ago https://news.ycombinator.com/item?id=12484248 647 days ago https://news.ycombinator.com/item?id=11318508 For those who already have read it, document has been addended multiple times (see bottom of doc)

> For those who already have read it, document has been addended multiple times (see bottom of doc)

Thank you, I was just wondering how up to date this is.

Re: FreeBSD – a lesson in poor defaults

#16

Post by ilammy » Tue, Dec 26, 2017, 5:50 PM UTC

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…

> 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 and more stuff, not having time to even run the OOM killer.

Maybe the systems use unencrypted swap to avoid triggering such bugs in default setups.

Re: FreeBSD – a lesson in poor defaults

#17

Post by wolf550e » Tue, Dec 26, 2017, 6:01 PM UTC

ilammy wrote: post #16

vog wrote: post #8

Earlier quoted context omitted.

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…

> 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.

Re: FreeBSD – a lesson in poor defaults

#18

Post by secret_island » Tue, Dec 26, 2017, 6:05 PM UTC

vog wrote: post #5

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

Long-time OpenBSD user here. OpenBSD has sane, secure defaults with nothing enabled in a fresh install. This is a desired default, as everyone uses OSes for different reasons. OpenBSD makes a phenomenal firewall, a pretty good Web server, and a super nice, secure file server.

OpenBSD shines because of the ongoing code audit, the minimalism, and the ability to easily make it into whatever you want. I don't care for any other OS for serious business. I will almost always use OpenBSD for servers, with RedHat or CentOS being the only other choice because of SELinux.

I would also venture to say that OpenBSD has the absolute best documentation of any OS out there, even better than FreeBSD.

Re: FreeBSD – a lesson in poor defaults

#19

Post by krylon » Tue, Dec 26, 2017, 6:11 PM UTC

> Being alerted to vulnerabilities in your installed packages is nice, but there's simply no need to be doing this operation as root. The dangerous combination of laziness and poor software design is quite prevalent here.

Just a thought - if an unprivileged user could download the vulnerability list, couldn't a malicious but unprivileged local user just "download" an empty vulnerability list? At least it would take a user account created specifically for this purpose. (Which I admit would be a good idea!)

Re: FreeBSD – a lesson in poor defaults

#20

Post by noinsight » Tue, Dec 26, 2017, 6:21 PM UTC

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.

Actually, Samsung 960 Pros are fast enough that encryption becomes a bottleneck, at least on my Xeon E5-2620v4.

You can test it yourself with `cryptsetup benchmark`:

    # cryptsetup benchmark --cipher aes-xts
    # Tests are approximate using memory only (no storage IO).
    #     Algorithm | Key |  Encryption |  Decryption
            aes-xts   256b  1874.2 MiB/s  2042.6 MiB/s

I was surprised and it made me doubt whether it's using AES-NI at all, but then again it's not an issue in practice.