Live data from Hacker News

Linux workstation security checklist

github.com

51–60 of 165 posts

Re: Linux workstation security checklist

#51

Earlier quoted context omitted.

Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details: https://wiki.archlinux.org/index.php/Unified_Extensible_Firm... It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification. So yeah. Laughing at this advice is at best uninformed. A n…

>On proper UEFI implementations ... You're going to have to qualify that.

It's no secret that the full UEFI spec is quite complex. Some parts are mandatory while others are optional.

It's also no secret that lots of hardware vendors are terrible at implementing software. The usual rule is that the less software they write, the better.

The result is that different vendors and OEMs have a different quality UEFI firmware implementations and different feature-set available in them. Some are clearly less proper and less complete than others.

Re: Linux workstation security checklist

#52
post #8

Not the soundest security advice I've read recently: > We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root). If you are the sole user of the laptop, then having your root password be different from your LUKS password has no meaningfu…

I'm struggling to understand any situation where you should ever be typing either your LUKS password or your root password into a fully operating/running system.

If you're using sudo correctly, you do not enter your root password. Frankly, the only time I can remember being prompted for a root password in years is when the system has failed to boot and offers entry to a recovery/maintenance shell.

If you're using LUKS correctly for your boot drive, you enter it only during startup before the system has booted.

If someone has access to your disk and has your LUKS key, the root password is merely a formality.

Re: Linux workstation security checklist

#54

I'm working on a fully encrypted laptop (LUKS, all partitions except boot/efi) and feel quite secure.

I have a fully airgaped and True-Crypt encrypted computer and don't feel secure at all. I guess it all depends on the attacker you envision and the trust (or lack thereof) you have in your encryption software.

Re: Linux workstation security checklist

#55
post #40
post #4

FireWire is a vulnerability for Linux only because the kernel maintainers want it to be. There's a register in FireWire controllers which controls the address range for which remote memory accesses are valid. It can be set to 0, which locks out that function. The last time I looked, years ago, it was set to allow access to the first 4GB of memory, because the code pre-dated 64 bit systems. I once proposed setting it…

Linux has, in fact, supported a configuration option CONFIG_FIREWIRE_OHCI_REMOTE_DMA (default n) since 2.6.26 released 13 July 2008. [0][1] In kernel 3.14, this was changed into a module parameter (default n). [2] I did not further investigate the status of firewire modules before then. I was unable to locate any relevant mailing list posts referencing "firewire" or "DMA" by the author "John Nagle". [3][4] [0] http:/…

Are these protections active before the kernel has booted?

Does DMA default to be off until enabled?

If firewire (and thunderbolt, expresscard) aren't DMA-free by default, then there's a time window before/during boot in which an attack could happen.

Full disk encryption/TPM/Secure Boot could help mitigate this though.

Re: Linux workstation security checklist

#56
post #8

Not the soundest security advice I've read recently: > We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root). If you are the sole user of the laptop, then having your root password be different from your LUKS password has no meaningfu…

Not to mention this gem: > it is fine to write down your passphrases and keep them in a safe place

The age-old "don't write your password down!" mantra is not meaningful without clarification.

That is essentially, of course, how password managers work!

There's no reason not to write a password down as long as it's securely stored. You probably need embarrassingly little physical security to store your password more safely than many dodgy website solutions!

I _still_ frequently get my _already set_ password emailed to me in plaintext either on sign-up, or when I click "forgotten". (The site is always treated to an angry email encouraging a thorough redesign - though not of course, a 'reply', which would give them even easier access to my password!)

Re: Linux workstation security checklist

#57
post #8

Not the soundest security advice I've read recently: > We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root). If you are the sole user of the laptop, then having your root password be different from your LUKS password has no meaningfu…

Not to mention this gem: > it is fine to write down your passphrases and keep them in a safe place

You left out the beginning and ending of that sentence:

> "Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk."

Re: Linux workstation security checklist

#58

I'm working on a fully encrypted laptop (LUKS, all partitions except boot/efi) and feel quite secure.

I have a fully airgaped and True-Crypt encrypted computer and don't feel secure at all. I guess it all depends on the attacker you envision and the trust (or lack thereof) you have in your encryption software.

What kind of breaches do you fear with your air-gapped setup?

Re: Linux workstation security checklist

#59
post #2

Nice list, until... install a closed source product that sends backups offsite (SpiderOak). wtf?

And, last I checked, SpiderOak's protocol actually has a flaw: they could potentially store a copy of one's initial key. I emailed them about this, but not response.

Cyphertite was really interesting, but it sounds like they're going out of business.

Post reply on HN