Live data from Hacker News

Linux workstation security checklist

github.com

111–120 of 165 posts

Re: Linux workstation security checklist

#111

Earlier quoted context omitted.

You don't need wheel to modify your terminal environment, $PATH or .bashrc. If your user account is compromised, your user account is compromised. Anything else is lipstick. And I agree that the typical sudoers config that allows opening terminals as root isn't a good idea. What I prefer lately is using a yubikey neo to ssh access a root shell. You can configure sudo and authorized_keys to allow directly opening a ro…

You misread my post, what I meant was that your day-to-day account is vulnerable, since you run your applications with it. If that's the account belonging to wheel, once your user account is compromised the attacker is root as well. One should use a different account, hopefully harder to compromise since is used only for sudo. That said, I like your use of yubikeys, even better than the phone that's the sort of stuff…

Basically, this is a GNU vs BSD misunderstanding. On BSD, only wheel members can use su to become root after entering the root password. On GNU/linux anyone can su to root by entering the root password regardless of whether they belong to wheel or not.[0]

The confusion with respect to these guidelines is because some BSD-inspired GNU/linux distributions confugure their sudo to use a "wheel" group.

> once your user account is compromised the attacker is root as well

... but only if they also know the root password.

Anyway, the long and short of it is that on GNU/Linux, wheel is only relevant on distributions that use wheel in their default sudo config.

[0] https://unix.stackexchange.com/questions/4460/why-is-debian-...

Re: Linux workstation security checklist

#112
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.

Re: Linux workstation security checklist

#113

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…

> 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."

Re: Linux workstation security checklist

#114

Earlier quoted context omitted.

> 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 command reminds them they're acting as root. I do not think that is accurate. As I remember it, sudo gained popularity because it provided better control over access to the "root passwor…

Sudo provides: 1) A mechanism to provide better control over access to root privileges where administrative access must be shared between multiple users. 2) An auditing mechanism to record both operations completed as the root user, as well as failed attempts to perform operations as root (usually authentication failures). 3) A way to remind the user that commands are running as root, as well as a way to avoid accide…

Well, yeah. But that's not why sudo became popular.

Re: Linux workstation security checklist

#115
post #113

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…

> 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 avoi…

Ya, all of a paragraph. Any security document, even something as basic as an internal policy statement about passwords, should begin with a thorough discussion of the threats that were in the minds of the drafters. Security is heavily a matter of opinion and perspective. The background on which those are based is therefore as important as the individual recommendations.

Re: Linux workstation security checklist

#116

Earlier quoted context omitted.

You misread my post, what I meant was that your day-to-day account is vulnerable, since you run your applications with it. If that's the account belonging to wheel, once your user account is compromised the attacker is root as well. One should use a different account, hopefully harder to compromise since is used only for sudo. That said, I like your use of yubikeys, even better than the phone that's the sort of stuff…

Basically, this is a GNU vs BSD misunderstanding. On BSD, only wheel members can use su to become root after entering the root password. On GNU/linux anyone can su to root by entering the root password regardless of whether they belong to wheel or not.[0] The confusion with respect to these guidelines is because some BSD-inspired GNU/linux distributions confugure their sudo to use a "wheel" group. > once your user ac…

Right, I kept using "wheel" to mantain the terminology in the github page, but clearly this created confusion.

But my point was that, regardless of whether you use sudo or su, on GNU/Linux or on *BSD, if the account used to elevate priviledges is compromised, the next you elevate you priviledges you should expect the attacker to follow you.

This is what I meant by "the attacker is root as well": it's just a matter of waiting for the next time you use su or sudo.

Re: Linux workstation security checklist

#117
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 LUK…

If you have unrestricted sudo, which is how most single-user systems are set up, your password is effectively the root password.

Re: Linux workstation security checklist

#118
post #36

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.

Modern systems have enough ram that swap is not much used. If it becomes necessary, the overhead of encrypting will be the least of your concerns. If your system is swapping, it's crawling anyway.

Re: Linux workstation security checklist

#119
post #37
post #13

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/

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)

Funny tidbit. I spun up a DO box (luckily it wasn't too important) to do some tasks on.

I set the root password (over ssh) to something random but only 8 characters. I meant to change it to use only keys, of course, but the machine was compromised in under an hour!

Re: Linux workstation security checklist

#120
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.

Post reply on HN