[deleted]
Linux workstation security checklist
151–160 of 165 posts
Re: Linux workstation security checklist
#152Earlier quoted context omitted.
> If you have unrestricted sudo [...] your password is effectively the root password. Yes, but it keeps an audit trail of who's account was compromised, etc.
With root privilege you can erase all of the audit logs. A malicious attack probably would do so if he/she cares about that.
You can't erase remote logs, or logs written to a write-only logging device (the one's I've seen seem essentially to be a serial port/usb device that emulates a line printer).
Re: Linux workstation security checklist
#153Earlier quoted context omitted.
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 LUK…
If you have unrestricted sudo, which is how most single-user systems are set up, your password is effectively the root password.
True, but that seems tangential to the question of whether using the same password for both the root account and LUKS encryption is bad advice.
Re: Linux workstation security checklist
#154Not 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 LUK…
Sudo is more often than not a security risk. If a program is not made to run as root it is usually because it would give too much power to a user (ie sudo mount is supid).
Add that to not having a root password and you have a single (weaker) point of failure (wheel group).
Re: Linux workstation security checklist
#155Meh. 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.
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.
Re: Linux workstation security checklist
#156Why 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...
Check out http://hardening.io - not quite a wizard, but a good start.
Re: Linux workstation security checklist
#157Any 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…
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).
Re: Linux workstation security checklist
#158It may be silly to ask[1] but is there a similar list for Mac OS X? [1] Silly because, you know, closed source
Take a look at this guide: https://github.com/drduh/OS-X-Yosemite-Security-and-Privacy-...
Re: Linux workstation security checklist
#159Nice 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.
That's why SpiderOak moved from browser-based signup to in-app signup, to eliminate this possibility. (The switch was made in April 2015.)
discaimer: I work for SpiderOak, but the response is my own.
Re: Linux workstation security checklist
#160Earlier quoted context omitted.
Well, that's really the question, isn't it? Is there more security added by enabling UEFI, or keeping it disabled? I managed to brick four Lenovo Thinkpad T540p mainboards due to a UEFI bug. Fortunately I had the on-site corporate maintenance contract (that time it paid for itself), because neither I nor Lenovo could figure out why the system would end up getting so badly bricked it couldn't be booted at all. Turns o…
Good questions all together. But if I were to make one technical nitpick... > Is there more security added by enabling UEFI, or keeping it disabled? You're not really disabling the UEFI firmware at a technical level. You're just telling the UEFI firmware to load a UEFI BIOS compatibility shim, which then proceeds to load a unverified bootloader instead. How much security do you expect to gain from that? I don't think…
Well, the question is kind of moot, because I haven't dared to re-enable UEFI boot since. Supposedly newer BIOS's have the bug fixed, but the value to me in risky another range of motherboard replacements is just not worth it. I suppose if I cared about UEFI it might be a good idea to try it before the maintenance contract runs out, but as a kernel developer, I'm constantly replacing the kernel, so using UEFI is a PITA anyway.