Linux workstation security checklist • Hacker News Board

Re: Linux workstation security checklist

#101

Post by jldugger » Fri, Aug 28, 2015, 5:06 PM UTC

linuxkerneldev wrote: post #41

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.

IMO the Linux Foundation serves three functions:

1. It manages assets: a. Linux intellectual property, like the Linux trademark. b. It secures funding and invests the proceeds to establish fellowships for kernel developers. c. It manages computer hardware for kernel developers.

You remember how https://en.wikipedia.org/wiki/Kernel.org#2011_attack was a thing? It seems reasonable for the people who's job it is to operate computer hardware to publish guidelines on securing their own workstations, and those of kernel devs who randomly have root access on kernel.org.

Re: Linux workstation security checklist

#102

Post by wyldfire » Fri, Aug 28, 2015, 5:12 PM UTC

eoranged wrote: post #100

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're no worse off than you would be without TPM?

Re: Linux workstation security checklist

#103

Post by fluidcruft » Fri, Aug 28, 2015, 5:15 PM UTC

forgottenpass wrote: post #98

baghira wrote: post #88

Earlier quoted context omitted.

Sure, 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. See also the fact that OSX ships with tty_tickets disabled. Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.

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…

> 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 password" for teams of administrative staff. sudo was lightyears easier and provided much more fine-grained control than figuring out how to design POXIX groups.

Re: Linux workstation security checklist

#104

Post by Thaxll » Fri, Aug 28, 2015, 5:23 PM UTC

mhurron wrote: post #89

Thaxll wrote: post #75

Setting SElinux on enforcing mode on a desktop is almost impossible.

Works for me. SELinux is enforcing by default on Fedora and I've never had to change it.

Do you add any software that you use into SElinux? Otherwise SElinux is useless.

Re: Linux workstation security checklist

#105

Post by baghira » Fri, Aug 28, 2015, 5:25 PM UTC

fluidcruft wrote: post #93

baghira wrote: post #76

Earlier quoted context omitted.

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…

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 that should be triggered using a smartwatch.

Re: Linux workstation security checklist

#106

Post by ultramancool » Fri, Aug 28, 2015, 5:33 PM UTC

nly wrote: post #96

mingus68040 wrote: post #78

Earlier quoted context omitted.

And yet, the primary use-case for file system encryption is to protect data at rest, from someone with physical access to the disk. It seems odd to draw the line at physical security so arbitrarily -- that you'd be willing to encrypt your entire root file system and then throw your hands in the air when it comes to securing a tiny boot partition.

I mainly encrypt in case of theft, /boot contains nothing valuable. / contains a lot of information about my configuration, and installed packages, as well as the key to /home

Yeah, encrypting for theft or so you have piece of mind while the machine is off but in sight is a completely valid use case.

It all depends on your threat model. In the case someone is taking the machine from me while it is off (ie: most theft or legal problems), I have a chance given FDE.

In case someone has physical access to the machine without me around, I have little to no chance, no matter what I do.

A threat model which includes an attacker having potential physical access to a machine to perform an evil maid or other blackbag cryptanalysis is a threat model which is very difficulty to accommodate, and indeed replaced boot files are just the start of your problems.

A threat model without this however, has no reason to necessitate secure boot.

As such, I see no gain in using UEFI or SecureBoot as this guide outlines. It worries me that the author didn't consider a realistic threat model when writing this guide.

This guide also suggests:

> Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk.

So it's highly confusing what sort of threat model the author had envisioned this to be written for.

Re: Linux workstation security checklist

#107

Post by baghira » Fri, Aug 28, 2015, 5:34 PM UTC

forgottenpass wrote: post #98

baghira wrote: post #88

Earlier quoted context omitted.

Sure, 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. See also the fact that OSX ships with tty_tickets disabled. Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.

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 somehow results in greater awareness, but this is purely an opinion of mine.

The other big reason for using sudo is the ability to change policy wrt which users can be root without changing root password everytime, and that clearly is true.

Re: Linux workstation security checklist

#108

Post by [deleted] » Fri, Aug 28, 2015, 5:38 PM UTC

forgottenpass wrote: post #98

baghira wrote: post #88

Earlier quoted context omitted.

Sure, 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. See also the fact that OSX ships with tty_tickets disabled. Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.

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…

[deleted]

Re: Linux workstation security checklist

#109

Post by JonathonW » Fri, Aug 28, 2015, 5:39 PM UTC

fluidcruft wrote: post #103

forgottenpass wrote: post #98

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…

> 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 accidentally running commands as root, since you're never (without "sudo -i" or "sudo -s" or similar) at an actual root shell.

If you're using "sudo -i"/"sudo -s" all the time, you don't lose anything for #1, and losing #3 is mostly just an inconvenience (it's an extra layer of protection, but it's not even really foolproof even with sudo). Losing #2 (auditing) can be a big deal, though, because, if everything's happening at a root shell (rather than via the sudo command), you lose the audit log that traces what's being done at root. Gaps like that in audit logs should be an indicator that something bad might've happened, but you can't make that assumption if you're routinely doing it yourself, too.

Re: Linux workstation security checklist

#110

Post by collyw » Fri, Aug 28, 2015, 5:57 PM UTC

nadams wrote: post #62

collyw wrote: post #45

Earlier quoted context omitted.

I have Linux on all my home machines, and none are configured to be accessed remotely. There are still plenty of advantages. Far less viruses / malware / crapware. Better performance on under powered machines. Better development environment (for the sort of development I do). No phoning home to MS / Apple (as far as I am aware).

> I have Linux on all my home machines, and none are configured to be accessed remotely. There are still plenty of advantages. Far less viruses / malware / crapware. I don't think the 2 ideas are related. I can't think of a script kiddie that would brute force your SSH to install a virus on it. Join a botnet maybe - but probably not to just install a virus. Also if you use something like SSH keys or OTP - it's pretty…

I think I would need to configure my router to port forward ssh before they could do that.(Or am I being dumb assuming that they can't get around that?)

Anyway my point was that Linux has plenty of advantage (for me) without being remotey accessed.