131–140 of 165 posts
Earlier quoted context omitted.
Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.
Have you never used more than one disk in a machine? Locked out of a machine because /var/log is full?
And no, only /tmp has reached capacity for me when building large packages with Archs makepkg.
Earlier quoted context omitted.
it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every co…
Sure, although I never found that reason to hold much ground given that in reality most distros ship with accounts that can open a shell (instead of having a list of allowed commands) and have the timeout not set to zero, so any security benefit that would come from not using "sudo -s" is pretty much voided. And I'm skeptical that having users type sudo a bunch of time when they add a PPA and install a program someho…
> Has a robust MAC/RBAC implementation (SELinux/AppArmor/Grsecurity) (CRITICAL)
This is too specific; there are plenty of operating systems with a much better security track record than even GNU/Linux that don't implement MAC or RBAC (namely, OpenBSD), and it misses the point of MAC/RBAC: privilege separation. Really, the goal here is for any given program to only have the minimum necessary permissions required for it to do its job. You can do this quite effectively by keeping running services/daemons isolated to dedicated users with a minimum permission set (this is, in fact, the core of how Android apps are sandboxed), especially when paired with a proper sandboxing solution.
The nice thing about MAC and RBAC is that they have policy implications; when used properly, they can clearly define the level of access some running program should have to a given part of the system. They also tend to go hand-in-hand with fine-grained control over resource access, but it's not correct to conflate access control mechanisms with granularity (you can have a fine-grained DAC-based system or a coarse-grained MAC-based system).
> Use full disk encryption (LUKS) with a robust passphrase (CRITICAL)
Or (inclusively) a key file (preferably one which is password protected).
> Make sure swap is also encrypted (CRITICAL)
Or just don't use swap. Even with encryption, if data can be ephemeral, it should be.
> Set up a robust root password (can be same as LUKS) (CRITICAL)
I very strongly disagree with this. As much as I dislike Ubuntu, it does one thing right: it defaults to disallowing any sort of direct root login (by setting root's password to some randomly-generated garbage during installation, IIRC), requiring all root access to be done with sudo unless the user explicitly sets a root password.
I especially very strongly disagree with the suggestion that the disk encryption password should be the same as any other password, let alone the root password that shouldn't exist in the first place (well, more precisely, should exist but should be entirely unknown to anyone or anything, including yourself).
> Globally disable firewire and thunderbolt modules (CRITICAL)
This, along with the recommendations to not use hardware with such ports, should be marked as (PARANOID). While it's certainly a good idea if you know they won't be necessary, there are plenty of valid use cases for them (particularly on Apple hardware; while Thunderbolt display support is still sketchy on Linux, it's still a very common use case), and such actions meet (PARANOID)'s criteria much closer than they do (CRITICAL)'s.
And really, while FireWire and Thunderbolt do have specific security implications (due to them effectively being hotpluggable PCI and PCI-E, respectively), this should hold true for any port on one's machine. Any connector can be a security liability when confronted with a sufficiently-motivated attacker.
> Configure the screensaver to auto-lock after a period of inactivity (MODERATE)
This needs to be (HIGH), if not (CRITICAL). Why bother with some FireWire jig like what this guide is so afraid of when the machine's already unlocked?
> Installing rkhunter and an intrusion detection system (IDS) like aide or tripwire will not be that useful unless you actually understand how they work and take the necessary steps to set them up properly
None of the things in this guide will be that useful unless you actually understand how they work and take the necessary steps to set them up properly. None of them. Not MAC. Not RBAC. Not grsecurity and PaX. Not SELinux. Not LUKS. Not passwords. Nothing. This sentence is entirely meaningless.
Not to mention that rkhunter should probably be (MEDIUM)...
> SSH is configured to use PGP Auth key as ssh private key (MODERATE)
What? That's a terrible idea. It's as terrible an idea as using the same password for root and LUKS. If one key is compromised, now the other is, too, because they're the same key.
This is really just a waste of effort and time. The normal approach is to just generate two separate keys, and there's no reason to deviate from this; doing so will just make your life harder and less secure.
Earlier quoted context omitted.
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.
It's the annoying times when your system forces you in to single user mode for repairs, and you have to enter something... or else boot up a rescue disk (the proper solution) to fix it, that make having a root password at all a sometimes good idea. Really though, that rescue disk sounds like a better idea every time I think about the situation.
Even without, IIRC, Ubuntu (one of the few systems that actually gets root passwords right by defaulting to it being randomly-generated garbage that nobody knows) will prompt for the credentials of a sudo-capable user even for single-user mode.
Earlier quoted context omitted.
Not to mention this gem: > it is fine to write down your passphrases and keep them in a safe place
Why not? Write them all on a piece of paper and lock it in a safe. Probably much safer than a password manager.
() Unless you either turn that force into the energy required to brute-force the passphrase/keyfile or use it in a way that invokes xkcd #538.
Earlier quoted context omitted.
Why not? Write them all on a piece of paper and lock it in a safe. Probably much safer than a password manager.
Absolutely. I use a password manager for everything except a handful of ultra-critical sites, mostly things involving money or attack vectors to get access to my email. For those sites I don't trust to store in LastPass, I write the passwords down on paper. But I also do something I haven't seen others recommend: Have a (logical) salt for all of the passwords. Don't write down that salt. So, if you found my piece of…
Ideally, you'd just set "In 1999 I bought my first stock as a young man. I wish I bought more of it." as your actual password :)
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…
That's a stupid excuse, they should put the flag to flip that bit in the kernel-hacking menu of menuconfig.
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.
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.
If you do have swap, though, then the encryption probably won't matter much compared to the fact that your machine is swapping in the first place.
Earlier quoted context omitted.
You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.
Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.