The analysis is not in any way serious, just some feelings the author has about certain things that may not even matter to anyone nor improve security in any meaningful way, if not worsen it by providing a false sense of security.
FreeBSD – a lesson in poor defaults
21–30 of 72 posts
Re: FreeBSD – a lesson in poor defaults
#22Earlier 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.
Even if a modern CPU can to do, the question is whether on a stock distro kernel they will do that. I could see the default kernels not being compiled with the extensions that may allow that speed for compatibility purposes. Then again, I remember when distros often shipped different i386, i586 and i686 kernels, and when Red Hat switched away from i386 as the default kernel (which might be a lot more recent than you think, if you weren't thinking of all the cheap i386 devices it was still working on in the early 2000's). Then, even if the stock kernel does support it through a kernel module, the question is whether that module was loaded. Finally, from looking at an Intel/AMD AES intructions compatibility list[1], not all processors as of even a couple years ago supported AES instructions (notably, it appears Intel used it to differentiate the i3 line from the more powerful ones)..
1: https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_...
Re: FreeBSD – a lesson in poor defaults
#23Earlier 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.
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, b…
cryptsetup benchmark --cipher aes-xts
# Tests are approximate using memory only (no storage IO).
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 2266.2 MiB/s 2273.8 MiB/s
21.86% cryptsetup [aesni_intel] [k] _aesni_dec4
19.83% cryptsetup [aesni_intel] [k] _aesni_enc4
17.80% cryptsetup [aesni_intel] [k] aesni_xts_crypt8
13.73% cryptsetup [kernel] [k] copy_user_generic_unrolled
2.20% cryptsetup [kernel] [k] get_page_from_freelist
1.86% cryptsetup [glue_helper] [k] glue_xts_crypt_128bit
1.53% cryptsetup [kernel] [k] put_page
1.36% cryptsetup [kernel] [k] blkcipher_walk_done
https://github.com/torvalds/linux/blob/master/arch/x86/crypt...
I don't know if using AVX would speed it up. openssl is faster (openssl speed -evp aes-256-gcm and aes-256-xts).
Re: FreeBSD – a lesson in poor defaults
#24Reminds me of the old "Fixing Solaris" file from the '90s (and the Fixing SunOS that was its forebear.)
Is it archived anywhere?
Re: FreeBSD – a lesson in poor defaults
#25> 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…
A compromised unprivileged user could download an empty vulnerability list. A compromised root user could download an empty vulnerability list or do anything else root can do.
Re: FreeBSD – a lesson in poor defaults
#26Earlier 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…
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.
Re: FreeBSD – a lesson in poor defaults
#27> 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…
Sure, they'll have an encrypted SWAP, and an unencrypted swap, and developers will choose which to use. Leverage Unix's case-sensitivity.
/s
Re: FreeBSD – a lesson in poor defaults
#28As 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.
Re: FreeBSD – a lesson in poor defaults
#29Earlier 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…
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?
Re: FreeBSD – a lesson in poor defaults
#30Earlier 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…
In my experience, linux locking up for minutes at a time while in a swapping situation happens if the disk is encrypted or not, and is a function of a crappy swapping algorythm.