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 meaningful security advantages.
Your root password is much easier to steal than your disk encryption password. Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc, or sniff it from an unrelated X11 window, or use a microphone. A microphone is far more likely to pick up your root password than a password typed once at boot. If the root password is sniffed with a microphone, the attacker might not even have root access to your system over the network. If stolen with evil-sudo or via X11, you might realize you've been compromised before all of your data is exfiltrated. Neither scenario should let the attacker then steal your disks and be able to decrypt all of your data. Unless you follow the advice.
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.
Frankly, I find it suspect that they even suggest having a root password. The only situation where this is useful is when sudo is somehow broken (e.g. a typo in /etc/sudoers). This happens rarely enough that I'm OK with a more heavyweight process (like booting Knoppix) to fix it.
To all those writing the critical comments: I'd love to read a rebuttal to this written by someone who is a Linux and security professional, and explaining not only what is wrong here but why in addition to best security practises. Thanks.
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 to 0. This was rejected because there are kernel debuggers which use 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]
Nice checklist, signa11. But there are few moments which I should point:
1. TPM on recent Intel hardware is controlled by Intel Management Engine (http://libreboot.org/faq/#intelme) which basically acts as a hardware backdoor which cannot be disabled or controlled in most cases.
2. About firewalling: It's good to filter out even ping from Internet (it's almost always fine to keep it enabled for lan segment) to make automatic detection slightly harder (LOW). BTW, installing coreboot instead of manufacturer-provided firmware (if possible) also could be good improvement (PARANOID).
3. As for browser(and skype and all the rest of Internet applications) It's good thing to block and audit strange actions such as attempts to access ssh or pgp/gpg keys. By audit I mean set up quite visible and persistent notification. (MEDIUM)
> 1. TPM on recent Intel hardware is controlled by Intel Management Engine (http://libreboot.org/faq/#intelme) which basically acts as a hardware backdoor which cannot be disabled or controlled in most cases.
Seems kinda like this point is conceded: "plus there is a pretty high degree of certainty that state security agencies have ways to defeat it (probably by design) ..."
Other than perhaps misplaced faith, you're no worse off than you would be without TPM?
Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. I like to keep things simple (which is why I use syslinux instead of GRUB as a bootloader. GRUB2 is ugly as sin to configure)
On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.
> Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right.
Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?
Self-Destructing Cookies is an absolute must. It's fantastic practice that makes sure that you don't have any cookies persisting longer than they should, and really reduces your footprint.
It certainly makes sense from a security standpoint, but is there any additional overhead to encrypting swap? This is the first time I've ever seen it mentioned as a security measure.
Any security checklist should start with a description both how the machine is to be used and the expected threats models. There are plenty of things in this list that I disagree with, but only because I am looking at different security needs.
For instance: I see no mention of Tor or VPNs. So this workstation isn't concerned with APT-style threats, or anyone else with the ability to manipulate network connections at a high level. And my quick read sees no talk of memory encryption or any of the physical measures for countering cold-boot scenarios.
This is not a workstation for international (China) travel or for protecting against surveillance. It has some good advice, but is certainly not comprehensive.
> Any security checklist should start with a description both how the machine is to be used and the expected threats models.
It states right at the top that the target audience is Linux sysadmins and their workstations.
> It has some good advice, but is certainly not comprehensive.
"This, by no means, is an exhaustive "workstation hardening" document, but rather an attempt at a set of baseline recommendations to avoid most glaring security errors without introducing too much inconvenience."
Make sure you check the regs for China before modifying machines for said travel; a few years back I was supposed to head there (didn't due to a snafu), and encrypted my normal stays-at-work laptop's drive (among other measures), but it turns out that I'm not allowed to bring an encrypted device in without advance permission. Might be able to get away with it, but what happens should it be detected?
If I was going to China and really needed to bring a machine, I'd bring a Chromebook with some means to run Linux and the minimum needed to pull critical items... and it would get binned upon return, preferably without being powered up anywhere near any means to connect out (though I'd probably want to ensure it was wiped).
The other backup suggestion's odd too - make a good backup disk passphrase, store it in your password manager. (where's the password manager backed up?)
I was using Wuala but they are closing it down later this year, starting from now. They recommend switching to Tresorit, Swiss based with end to end encryption and no keys held on the server (lose your password at your peril). Any recommendations for cloud storage that is secure and has a Linux GUI? Tresorit is not open source either as far as I can tell from the website.
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.
I always install fail2ban so to prevent brute force ssh attacks from getting in. It's popular enough that's it's probably available in your distro's package repositories.
Also, don't use SSH passwords. Authenticate only with SSH keys.
An SSH private key is almost impossible to brute force, compared to passwords. (unless your SSH key generator has been patched by a clueless Debian maintainer)
For my home computer, sshd is always on. It is configured to disable password authentification. On the firewall, I authorize only two things: ssh port and wakeonlan. If I need to access another port, it is generally enough to open temporarily a ssh tunnel.
I think that you lose most of the advantages of a unix computer if you can not access it remotely.
Why can't someone simply make a security wizard for Linux. Like I run the program and it gives me options and changes the settings based on my selections. Why must everything be so manual everytime on Linux...
This was a nice presentation comparing security in general to how cars were built in the 1960's, when engineers made the car work great - but with little consideration for "user error" or the user experience in general. 50 years later cars are highly protected against dumb things the user might do, and he suggests that's how the security community should look at building stuff, too(while hopefully not taking another 50 years to achieve great security with great user experience as well).
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 nice bonus-effect from using secure boot is that most UEFI implementations secure-boot faster. Why? Because when in "insecure" mode it keeps up a splash-screen saying "Booting insecure" for a few seconds before moving on.
So.. mostly use SELinux and UEFI?
This is NOT the advice I wanted to hear.
Maybe I needed to hear it, but both of these things (last I tried them) were a giant messy pain in the rear end. And from what little I understand, both have parties involved in their creation/promotion (MS, NSA) that might don't have stellar open source/privacy pedigrees.
Maybe worth another look.... IDK. But for now... I turn both off.
Wasn't the Linux Foundation supposed to be just an umbrella org that provided employment to key Linux devs? So that they could be independent from corporate influence and work indepently/freely without corporate interference.
[+] [-] ivank|10 years ago|reply
> 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 meaningful security advantages.
Your root password is much easier to steal than your disk encryption password. Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc, or sniff it from an unrelated X11 window, or use a microphone. A microphone is far more likely to pick up your root password than a password typed once at boot. If the root password is sniffed with a microphone, the attacker might not even have root access to your system over the network. If stolen with evil-sudo or via X11, you might realize you've been compromised before all of your data is exfiltrated. Neither scenario should let the attacker then steal your disks and be able to decrypt all of your data. Unless you follow the advice.
[+] [-] fluidcruft|10 years ago|reply
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.
[+] [-] amalcon|10 years ago|reply
[+] [-] hnnh|10 years ago|reply
That's only going to get you the user's password, not the root password.
[+] [-] woebtz|10 years ago|reply
Is audio analysis of keyboard chatter a thing or are we leaking passwords when we verbally communicate them to a co-worker?
I don't think this is related, but I found this keylogging technique combining microphone, camera, accelerometer data to approximate finger/thumb positions for PIN numbers: http://www.cl.cam.ac.uk/~rja14/Papers/pinskimmer_spsm13.pdf
[+] [-] satai|10 years ago|reply
[+] [-] SturgeonsLaw|10 years ago|reply
> it is fine to write down your passphrases and keep them in a safe place
[+] [-] wyclif|10 years ago|reply
[+] [-] pakled_engineer|10 years ago|reply
[+] [-] Animats|10 years ago|reply
I once proposed setting it to 0. This was rejected because there are kernel debuggers which use it.
[+] [-] Hello71|10 years ago|reply
I was unable to locate any relevant mailing list posts referencing "firewire" or "DMA" by the author "John Nagle". [3][4]
[0] http://cateee.net/lkddb/web-lkddb/FIREWIRE_OHCI_REMOTE_DMA.h...
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
[3] http://search.gmane.org/?query=firewire&author=John+Nagle
[3] http://search.gmane.org/?query=dma&author=John+Nagle
[+] [-] noja|10 years ago|reply
[+] [-] Qantourisc|10 years ago|reply
[+] [-] eoranged|10 years ago|reply
1. TPM on recent Intel hardware is controlled by Intel Management Engine (http://libreboot.org/faq/#intelme) which basically acts as a hardware backdoor which cannot be disabled or controlled in most cases.
2. About firewalling: It's good to filter out even ping from Internet (it's almost always fine to keep it enabled for lan segment) to make automatic detection slightly harder (LOW). BTW, installing coreboot instead of manufacturer-provided firmware (if possible) also could be good improvement (PARANOID).
3. As for browser(and skype and all the rest of Internet applications) It's good thing to block and audit strange actions such as attempts to access ssh or pgp/gpg keys. By audit I mean set up quite visible and persistent notification. (MEDIUM)
4. Also, It would be great to add links to NSA Linux Configuration guide (http://www.nsa.gov/ia/mitigation_guidance/security_configura...) and CIS Security Benchmarks (http://benchmarks.cisecurity.org/downloads/browse/index.cfm?...).
[+] [-] wyldfire|10 years ago|reply
Seems kinda like this point is conceded: "plus there is a pretty high degree of certainty that state security agencies have ways to defeat it (probably by design) ..."
Other than perhaps misplaced faith, you're no worse off than you would be without TPM?
[+] [-] nly|10 years ago|reply
On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.
[+] [-] darkr|10 years ago|reply
Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?
[+] [-] jszymborski|10 years ago|reply
[+] [-] SmellyGeekBoy|10 years ago|reply
[+] [-] sandworm101|10 years ago|reply
For instance: I see no mention of Tor or VPNs. So this workstation isn't concerned with APT-style threats, or anyone else with the ability to manipulate network connections at a high level. And my quick read sees no talk of memory encryption or any of the physical measures for countering cold-boot scenarios.
This is not a workstation for international (China) travel or for protecting against surveillance. It has some good advice, but is certainly not comprehensive.
[+] [-] mricon|10 years ago|reply
It states right at the top that the target audience is Linux sysadmins and their workstations.
> It has some good advice, but is certainly not comprehensive.
"This, by no means, is an exhaustive "workstation hardening" document, but rather an attempt at a set of baseline recommendations to avoid most glaring security errors without introducing too much inconvenience."
[+] [-] syntheticnature|10 years ago|reply
If I was going to China and really needed to bring a machine, I'd bring a Chromebook with some means to run Linux and the minimum needed to pull critical items... and it would get binned upon return, preferably without being powered up anywhere near any means to connect out (though I'd probably want to ensure it was wiped).
[+] [-] noja|10 years ago|reply
[+] [-] mkj|10 years ago|reply
[+] [-] kagamine|10 years ago|reply
[+] [-] wtbob|10 years ago|reply
Cyphertite was really interesting, but it sounds like they're going out of business.
[+] [-] mricon|10 years ago|reply
[+] [-] oofabz|10 years ago|reply
http://www.fail2ban.org/
[+] [-] vog|10 years ago|reply
An SSH private key is almost impossible to brute force, compared to passwords. (unless your SSH key generator has been patched by a clueless Debian maintainer)
[+] [-] praseodym|10 years ago|reply
http://www.sshguard.net/
https://github.com/fail2ban/fail2ban/issues/1123
[+] [-] m4r71n|10 years ago|reply
[+] [-] reacweb|10 years ago|reply
I think that you lose most of the advantages of a unix computer if you can not access it remotely.
[+] [-] cranium|10 years ago|reply
[1] Silly because, you know, closed source
[+] [-] brador|10 years ago|reply
[+] [-] icebraining|10 years ago|reply
[+] [-] mtgx|10 years ago|reply
http://kernsec.org/files/lss2015/giant-bags-of-mostly-water....
[+] [-] yellowapple|10 years ago|reply
Relevant documentation: http://doc.opensuse.org/documentation/html/openSUSE_121/open...
[+] [-] FireBeyond|10 years ago|reply
[+] [-] 616c|10 years ago|reply
I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have someone other than Microsoft have the key.
But seriously, did anyone else laugh?
[+] [-] josteink|10 years ago|reply
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 nice bonus-effect from using secure boot is that most UEFI implementations secure-boot faster. Why? Because when in "insecure" mode it keeps up a splash-screen saying "Booting insecure" for a few seconds before moving on.
[+] [-] crdoconnor|10 years ago|reply
[+] [-] jqm|10 years ago|reply
Maybe I needed to hear it, but both of these things (last I tried them) were a giant messy pain in the rear end. And from what little I understand, both have parties involved in their creation/promotion (MS, NSA) that might don't have stellar open source/privacy pedigrees.
Maybe worth another look.... IDK. But for now... I turn both off.
[+] [-] vladimir-y|10 years ago|reply
[+] [-] federico3|10 years ago|reply
[+] [-] linuxkerneldev|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] w8rbt|10 years ago|reply
https://en.wikipedia.org/wiki/TOMOYO_Linux
[+] [-] Thaxll|10 years ago|reply
[+] [-] mhurron|10 years ago|reply
[+] [-] jeffreyrogers|10 years ago|reply