Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux workstation security checklist

github.com

Post reply on HN
Print view View original

21–30 of 165 posts

Re: Linux workstation security checklist

#21

Post by Qantourisc »

Animats wrote: post #4

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.

Re: Linux workstation security checklist

#23

Post by icebraining »

kagamine wrote: post #20
noja wrote: post #2

Nice list, until... install a closed source product that sends backups offsite (SpiderOak). wtf?

I was using Wuala but they are closing it down later this year, starting from now. They recommend switching to Tresorit, Swiss based with end to end encryption and no keys held on the server (lose your password at your peril). Any recommendations for cloud storage that is secure and has a Linux GUI? Tresorit is not open source either as far as I can tell from the website.

Tarsnap now has a GUI: https://github.com/Tarsnap/tarsnap-gui/wiki/Tarsnap

Re: Linux workstation security checklist

#24

Post by icebraining »

brador wrote: post #22

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

They have, it's called Bastille, and it's been around for quite a few years: http://bastille-linux.sourceforge.net/

Re: Linux workstation security checklist

#25

Post by reacweb »

For my home computer, sshd is always on. It is configured to disable password authentification. On the firewall, I authorize only two things: ssh port and wakeonlan. If I need to access another port, it is generally enough to open temporarily a ssh tunnel.

I think that you lose most of the advantages of a unix computer if you can not access it remotely.

Re: Linux workstation security checklist

#26

Post by 616c »

josteink wrote: post #12
616c wrote: post #7

SecureBoot!? Hahahah, Linux Foundation marks this as critical? I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have someone other than Microsoft have the key. But seriously, did anyone else laugh?

Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details: https://wiki.archlinux.org/index.php/Unified_Extensible_Firm... It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification. So yeah. Laughing at this advice is at best uninformed. A n…

I laugh, and get downvoted, because SecureBoot was a noble concept, and rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic.

I deal with computer deployment for a living. I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my self-signed certs unless it is not seriously work-related stuff. The majority of people, and I have a few budding Linux enthusiast friends, just turn off Secure Boot. Not to mention the numerous IT contractors I meet. It is embarassing.

UEFI is also a mess. I have recently read some good UEFI attack papers, and it scares me to no end, as the firmware extension capabilities make the B in BIOS increasingly seem more ironic. And the potential of having a FAT16/32 parttion of exploitable garbage from system vendors puts just back where we started.

I think this shit is great in theory, but in implementation I do not trust corporations with TPM devices, let alone SecureBoot. It works in principal, but only as long as you trust the US corporate and federal government interests.

For reasons long since expounded on HN and elsewhere, I do not.

Re: Linux workstation security checklist

#27

Post by brador »

icebraining wrote: post #24
brador wrote: post #22

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

They have, it's called Bastille, and it's been around for quite a few years: http://bastille-linux.sourceforge.net/

Last update in 2012...is it still workable?

Re: Linux workstation security checklist

#28

Post by kagamine »

icebraining wrote: post #23
kagamine wrote: post #20

Earlier quoted context omitted.

I was using Wuala but they are closing it down later this year, starting from now. They recommend switching to Tresorit, Swiss based with end to end encryption and no keys held on the server (lose your password at your peril). Any recommendations for cloud storage that is secure and has a Linux GUI? Tresorit is not open source either as far as I can tell from the website.

Tarsnap now has a GUI: https://github.com/Tarsnap/tarsnap-gui/wiki/Tarsnap

Nice, doesn't do Windows though which I am locked into at work, and is aimed solely at backups, not sharing and managing files over multiple computers and OSes which is what I was mainly using Wuala for. But you answered the question, so you get an Internet point.

Re: Linux workstation security checklist

#29

Post by SturgeonsLaw »

ivank wrote: 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…

Not to mention this gem:

> it is fine to write down your passphrases and keep them in a safe place

Re: Linux workstation security checklist

#30

Post by josteink »

616c wrote: post #26
josteink wrote: post #12

Earlier quoted context omitted.

Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details: https://wiki.archlinux.org/index.php/Unified_Extensible_Firm... It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification. So yeah. Laughing at this advice is at best uninformed. A n…

I laugh, and get downvoted, because SecureBoot was a noble concept, and rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic. I deal with computer deployment for a living. I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to…

rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic.

And that was a good thing. It put pressure on getting the capability to add your own keys.

I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my self-signed certs

Agreed. I guess it all depends on what you refer to as "security".

For me general internet security is about making it harder to get impacted by drive-by malware, portscans and similar.

I set as a general rule that I don't believe there exists practical security-measures which can counter-act malicious activity if anyone has local access to my hardware. I don't try to guard against that.

If your definition of "security" involves guarding against possible systematic attacks from US government agencies using pre-installed (Microsoft) keys, obviously secure boot is not going to provide that for you.

My point was that laughing at secure boot as a measure of increased security because "lulz Microsoft" is a knee jerk reaction which is factually wrong.

The majority of people, and I have a few budding Linux enthusiast friends, just turn off Secure Boot

And are you really going to tell me they are not more vulnerable than if they had been using secure boot?

Secure boot can be used to increase security and I don't think that is debatable. I think the reason you're getting downvoted is because you seemingly dismiss this point.

UEFI is also a mess

I think I'll have to agree with this one. With BIOS being clearly insufficient for modern hardware and software needs, UEFI was a pendulum move gone too far the other direction.

It's over-engineered, supports too many crazy things, and coupled with other "messy" features like Intel System Management mode (which also allows code outside the OS), the possible attack vectors (coupled with physical access) are getting increasingly crazy.

Post reply on HN