121–130 of 165 posts
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.
Earlier 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.
Yes, but it keeps an audit trail of who's account was compromised, etc.
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:/…
FireWire doesn't really have "DMA", anyway. It has some auxiliary functions to let the network controller get and set single memory words, one word per packet request/response. All bulk transfers use a different mechanism, which works more like an Ethernet controller, shipping blocks around into receiver-designated buffers. The "memory access" function is in there as a way to send commands to devices. This thing was designed by people who thought that storing bits into a control register was the proper way to talk to a dumb device. In practice, dumb devices now have some small processor, and the "memory access" function ends up being processed by a switch statement, to do "turn camera on" or some such function. There's no real reason for a PC-scale machine to need the DMA functions enabled, except for kernel debugging. That should be permanently disabled in all production systems.
Thunderbolt, on the other hand, apparently really exposes memory on an external cable as a normal function. That's how it extends the PCI bus to external devices. Not good for security.
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. http://www.fail2ban.org/
Why would you have sshd running on your workstation in the first place?
SSHd allows you to restrict particular users to IP ranges and of course you can use IP tables and fail2ban too.
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…
> 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'r…
Due to targeted attack or leak from Intel potential malware can use it to elevate privileges, hide from any type of audit, survive complete system reinstall and even be used to silently infect systems by remote entities.
And lack of TPM module allows to steal encryption password by application running with system privileges, which already have all required access anyway.
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…
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
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…
What do you mean by microphone? 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
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.
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…
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.
Really though, that rescue disk sounds like a better idea every time I think about the situation.
Earlier 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…
What I found problematic (unless I'm missing something) was the suggestion that your day-to-day user should be in the wheel group: if that's the case, once your user is compromised the attacker can edit .bashrc to change $PATH and use a patched sudo to take over the machine. IMHO "sudo" (or "doas") should be used from a different user, by switching to a different VT. Or at least only allowing certain commands for you…