Linux workstation security checklist

https://github.com/lfit/itpol/blob/master/linux-workstation-security.md

by signa11 • 11 years ago

376 160 11 years ago

noja2• 11 years ago

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

mkj• 11 years ago

The other backup suggestion's odd too - make a good backup disk passphrase, store it in your password manager. (where's the password manager backed up?)

kagamine2• 11 years ago

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.

icebraining2• 11 years ago

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

Skunkleton4• 11 years ago

The Deja-Dup front end for duplicity is built in to Ubuntu. It does encryption, and knows how to store in all sorts of places, including locally and on multiple cloud providers.

mricon4• 11 years ago

It's just mentioned in passing, alongside other recommendations.

wtbob2• 11 years ago

And, last I checked, SpiderOak's protocol actually has a flaw: they could potentially store a copy of one's initial key. I emailed them about this, but not response.

Cyphertite was really interesting, but it sounds like they're going out of business.

splme• 11 years ago

That's why SpiderOak moved from browser-based signup to in-app signup, to eliminate this possibility. (The switch was made in April 2015.)

discaimer: I work for SpiderOak, but the response is my own.

cranium• 11 years ago

It may be silly to ask[1] but is there a similar list for Mac OS X?

[1] Silly because, you know, closed source

satai2• 11 years ago

NSA [1] has pretty good list for major OSs.

[1] Yes, pretty ironic, isn't it?

dfc3• 11 years ago

No, it is not at all ironic that NSA provides STIGs for major operating systems. NSA is responsible for SIGINT and Information Assurance.

x0• 11 years ago

I mean, if anyone knows about computer security, it'd be them. Nice of them to share.

jlgaddis2• 11 years ago

There's the DISA STIG for OS X 10.10 [0].

[0] https://web.nvd.nist.gov/view/ncp/repository/checklistDetail...

noondip• 11 years ago

Take a look at this guide: https://github.com/drduh/OS-X-Yosemite-Security-and-Privacy-...

Animats2• 11 years ago

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 to 0. This was rejected because there are kernel debuggers which use it.

noja2• 11 years ago

Got a CVE or lkml link?

Qantourisc• 11 years ago

That's a stupid excuse, they should put the flag to flip that bit in the kernel-hacking menu of menuconfig.

yellowapple12• 11 years ago

Or default to that being disabled unless "debug" is passed in the kernel boot parameters.

Hello71• 11 years ago

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://cateee.net/lkddb/web-lkddb/FIREWIRE_OHCI_REMOTE_DMA.h...

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

[3] http://search.gmane.org/?query=firewire&author=John+Nagle

[3] http://search.gmane.org/?query=dma&author=John+Nagle

zdw• 11 years ago

Are these protections active before the kernel has booted?

Does DMA default to be off until enabled?

If firewire (and thunderbolt, expresscard) aren't DMA-free by default, then there's a time window before/during boot in which an attack could happen.

Full disk encryption/TPM/Secure Boot could help mitigate this though.

Animats2• 11 years ago

It's been over a decade since I looked at this. I wrote a FireWire camera driver for QNX around 2003, and looked at Linux to see how they did it. At that time, the upper limit for external memory requests was a hard-coded constant. The config parameter came later. I think this was discussed on USENET, but I can't find it right now.

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.

616c3• 11 years ago

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?

crdoconnor• 11 years ago

I didn't laugh but I got a bit suspicious about their true motivations as soon as I saw that.

mricon4• 11 years ago

Not everyone has an evil agenda. And, if you read the guide, it specifically mentions the downsides of SecureBoot and offers alternatives (AntiEvilMaid).

josteink4• 11 years ago

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 nice bonus-effect from using secure boot is that most UEFI implementations secure-boot faster. Why? Because when in "insecure" mode it keeps up a splash-screen saying "Booting insecure" for a few seconds before moving on.

roghummal• 11 years ago

On proper UEFI implementations ...

You're going to have to qualify that.

616c3• 11 years ago

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.

ivank4• 11 years ago

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 meaningful security advantages.

Your root password is much easier to steal than your disk encryption password. Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc, or sniff it from an unrelated X11 window, or use a microphone. A microphone is far more likely to pick up your root password than a password typed once at boot. If the root password is sniffed with a microphone, the attacker might not even have root access to your system over the network. If stolen with evil-sudo or via X11, you might realize you've been compromised before all of your data is exfiltrated. Neither scenario should let the attacker then steal your disks and be able to decrypt all of your data. Unless you follow the advice.

satai2• 11 years ago

Maybe prepare a pullrequest for this? ;)

hnnh• 11 years ago

Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc

That's only going to get you the user's password, not the root password.

ivank4• 11 years ago

Good point. I've toned down my comment because that root password would be getting typed in less often.

An attacker might still bring an evil-su in addition to an evil-sudo, though. And even if you're logging into that root user only in an another tty, it seems like an unnecessary risk to share the password with LUKS.

SturgeonsLaw• 11 years ago

Not to mention this gem:

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

gozo• 11 years ago

I don't see any problem with that. Physical security is much easier to manage than digital security.

OJFord• 11 years ago

The age-old "don't write your password down!" mantra is not meaningful without clarification.

That is essentially, of course, how password managers work!

There's no reason not to write a password down as long as it's securely stored. You probably need embarrassingly little physical security to store your password more safely than many dodgy website solutions!

I _still_ frequently get my _already set_ password emailed to me in plaintext either on sign-up, or when I click "forgotten". (The site is always treated to an angry email encouraging a thorough redesign - though not of course, a 'reply', which would give them even easier access to my password!)

jlgaddis2• 11 years ago

You left out the beginning and ending of that sentence:

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

anoother• 11 years ago

Good enough for Bruce Schneier:

https://www.schneier.com/blog/archives/2005/06/write_down_yo...

SmellyGeekBoy2• 11 years ago

Why not? Write them all on a piece of paper and lock it in a safe. Probably much safer than a password manager.

amalcon• 11 years ago

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.

mjevans• 11 years ago

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.

fluidcruft7• 11 years ago

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 LUKS correctly for your boot drive, you enter it only during startup before the system has booted.

If someone has access to your disk and has your LUKS key, the root password is merely a formality.

ivank4• 11 years ago

You are entirely correct and it is too bad I did not delete my comment in time. Here I am with an intense dislike of bogus criticism on HN and yet perpetuating some. Sleep before you post...

baghira5• 11 years ago

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 day to day user.

ams61102• 11 years ago

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

totony• 11 years ago

Sudo is more often than not a security risk. If a program is not made to run as root it is usually because it would give too much power to a user (ie sudo mount is supid).

Add that to not having a root password and you have a single (weaker) point of failure (wheel group).

woebtz• 11 years ago

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

dllthomas• 11 years ago

Audio analysis of keyboard chatter is a thing that had a proof of concept years ago. I have no idea how often it is done, but it is certainly plenty possible.

oofabz• 11 years ago

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/

m4r71n• 11 years ago

Why would you have sshd running on your workstation in the first place?

vacri• 11 years ago

I've ssh'd into colleagues' machines to help them with system problems, and they've ssh'd into mine to retrieve their VPN keys. Not all of my colleagues have ssh access to a common server somewhere.

I've also remoted into my workstation from home to do emergency work.

drjesusphd• 11 years ago

It's irreplacable when one occasionally works from home.

Skunkleton4• 11 years ago

So that you can ssh to it?

rythie• 11 years ago

To allow remote management tools to run. If there's one thing that'll make your systems insecure, it's letting everyone manage their own boxes.

SSHd allows you to restrict particular users to IP ranges and of course you can use IP tables and fail2ban too.

praseodym• 11 years ago

Alternatively, use SSHguard if you want/need IPv6 support.

http://www.sshguard.net/

https://github.com/fail2ban/fail2ban/issues/1123

vog• 11 years ago

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)

odonnellryan• 11 years ago

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!

yellowapple12• 11 years ago

Better yet: it's a workstation. There's a pretty solid chance you don't actually need sshd to be even running.

(Granted, this guide specifies that it's meant for sysadmins managing groups of workstations, in which case SSH access might be necessary for remote administration, but for most users, SSHing into a workstation is unnecessary.)

known• 11 years ago

Install http://wiki.debian.org/iptables

brador2• 11 years ago

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

icebraining2• 11 years ago

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

brador2• 11 years ago

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

mtgx• 11 years ago

This was a nice presentation comparing security in general to how cars were built in the 1960's, when engineers made the car work great - but with little consideration for "user error" or the user experience in general. 50 years later cars are highly protected against dumb things the user might do, and he suggests that's how the security community should look at building stuff, too(while hopefully not taking another 50 years to achieve great security with great user experience as well).

http://kernsec.org/files/lss2015/giant-bags-of-mostly-water....

yellowapple12• 11 years ago

Try YaST on openSUSE. Offers precisely what you're looking for (among other things; it's basically the Linux equivalent to Windows' Control Panel).

Relevant documentation: http://doc.opensuse.org/documentation/html/openSUSE_121/open...

FireBeyond• 11 years ago

Check out http://hardening.io - not quite a wizard, but a good start.

reacweb2• 11 years ago

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.

collyw2• 11 years ago

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

nadams• 11 years ago

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 much guaranteed that no one but you can access it.

reacweb2• 11 years ago

Today, my wife (at home) has called me (at work) because she could not launch chrome anymore. The disk was full. The files /var/log/kern.log and syslog were eating gigabytes. I was able to solve her problem remotely. I have also installed ubuntu on the computer of my old father who lives far. Regularly, I upload pictures (he is my backup for pictuers) and put a shortcut on his desktop.

nly5• 11 years ago

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.

darkr2• 11 years ago

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.

Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?

nly5• 11 years ago

If someone has physical access, they can remove my keyboard and install a hardware keylogger anyway. Updating my kernel image wouldn't be very effective given that it gets updated by Arch more often than it gets booted from.

SmellyGeekBoy2• 11 years ago

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.

Skunkleton4• 11 years ago

In theory anything could be in ram could also end up in swap. So yes, it is important. And yes, there is overhead, but it isn't too bad if your system isn't RAM constrained, and your CPU supports AES-NI or similar.

ams61102• 11 years ago

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.

yellowapple12• 11 years ago

Ideally, you wouldn't even have a dedicated swap partition. No data is always more secure than even the most perfectly-encrypted data.

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.

dfc3• 11 years ago

You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.

hueving• 11 years ago

I really do not understand the point of encrypting a subsection of your drive.

To prevent people from reading sensitive data on a stolen/lost laptop.

jokr004• 11 years ago

I'm assuming he specifically mentioned encrypting /home because it's on a different partition/disk? I'm guessing /usr is on the root partition which he said he encrypts.

darkr2• 11 years ago

I guess that /usr is probably on the same partition as his root.. But depending on the distro, and how the system is managed; it may be the case that every single file in /usr comes from a package, and can be cryptographically verified using your package manager (this is certainly possible with RedHat, Debian + derivatives at least). As long as /var or wherever your package DB lives is encrypted..

nly5• 11 years ago

Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.

jszymborski• 11 years ago

Self-Destructing Cookies is an absolute must. It's fantastic practice that makes sure that you don't have any cookies persisting longer than they should, and really reduces your footprint.

federico3• 11 years ago

Shameless plug: a software "checklist" for desktop users - https://github.com/FedericoCeratto/desktop-security-assistan...

jeffreyrogers• 11 years ago

Maybe if you need this much security just use OpenBSD? :)

codingvelocity• 11 years ago

Can you enlighten the uninformed what would make OpenBSD more secure by default? It's my firm belief that the only secure system in the world is one that no one can use, biggest security hole you can add is a person...

linuxkerneldev• 11 years ago

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.

jldugger• 11 years ago

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.

vladimir-y• 11 years ago

I'm working on a fully encrypted laptop (LUKS, all partitions except boot/efi) and feel quite secure.

jmnicolas2• 11 years ago

I have a fully airgaped and True-Crypt encrypted computer and don't feel secure at all. I guess it all depends on the attacker you envision and the trust (or lack thereof) you have in your encryption software.

lordsper• 11 years ago

What kind of breaches do you fear with your air-gapped setup?

okasaki• 11 years ago

PaX is not a MAC framework.

wyclif• 11 years ago

To all those writing the critical comments: I'd love to read a rebuttal to this written by someone who is a Linux and security professional, and explaining not only what is wrong here but why in addition to best security practises. Thanks.

pakled_engineer• 11 years ago

Encrypt the root emails instead of sending them cleartext, can easily write a small script to do this and not give away internal security information.

w8rbt• 11 years ago

I'm surprised that they left out Tomoyo as a MAC option. I thought it had a decent following.

https://en.wikipedia.org/wiki/TOMOYO_Linux

arca_vorago2• 11 years ago

This is an interesting list, and I don't see anything glaringly wrong ( a few personal preference subjects, but..), so here are my handful of extra tips on top:

1. You can encrypt grub in order to prevent single user mode et al boot attacks. It can also make FDE systems recovery a pita though.

2. They already said it, but GRSEC is where it's at. It's really the future of linux security enhancement, and while you can run it in tandem with SElinux et al, I find it's better to run GRSEC and just fine tune it. You will thank yourself for learning it.

3. These days, you need a HIDS, full stop. What good do logs do if you never know what happens or only check your logs once a week/month/year/never? After spending time trying all the main ones out, OSSEC is my HIDS of choice.

4. SSH: while fail2ban, denyh0sts, et al are all workable options along with the listed option tweaks, what I find to work the best in addition are two things. A) Obscure port. We all know security through obscurity isn't, but reducing scripties bogging stuff down and keeping your logs cleaner helps imho. (it's also the difference between a metric ton of log alert emails and only a few). B) Two factor all the things. I am using the Google pam module, "libpam-google-authenticator". I stopped trusting tor but some friends of mine swear by ssh over tor hidden service.

5. The bottom line is that the linux kernel is out of control at >10mil loc, and 0-days/1-days are prevalent. If you have an internet facing system, it's probably going to get compromised, what you really need is the ability to find out as soon as possible when it happens. What this boils down to is you don't want to lose your data, so you need encrypted backups and verifiable checksums/hashes, so that once you've brought up a fresh system, you can restore data asap. Another thing that factors into this is configuration scripts and management stuff. I really like ansible since it works over ssh/powershell. Can really save a lot of time.

If you really want security, you also need to start and run minimal. I would say self compiled is the best (use flag changes often prevent sploits that otherwise work) so gentoo/slackware/arch would be the best nix distros for this. Beyond that, BSD is still king of the security world imho, especially OBSD, but please give DragonFlyBSD a look. While it's not touted as a "secure" distro, it has a ton of features that make it sexy as hell and it needs security contribs if you have the time. If I were starting a fresh ISP, I would be using DBSD.

For those of us stuck wanting to game and do more fun stuff though, who live in a debian/fedora/ubuntu world, just keeping an eye on logs is really the best you can do. Also keep in mind impact on perf that FDE may have if you are a linux gamer.

Those are my main tips/tricks, but I'm sure both the article and I are missing things, so take it all with a grain of salt.

throwaway2048• 11 years ago

you cant encrypt all of grub, some bit of it has to load the rest.

nickpsecurity3• 11 years ago

You're leaving off two details in your otherwise nice list. First, the backups aren't going to help you in a targeted attack if the attacker can mess with them. For this reason, I always recommended write- or append-only storage for backups. Or a second copy on these made later (i.e. batch process). I used CD/DVD-R's.

Other thing is you've hit problem (0-days) without solution (isolation). There are numerous technologies, especially separation/MILS kernels, that can isolate damage inside one or more VM's. They can also run security-critical processes outside of them directly on the kernel or in their own VM. INTEGRITY Desktop, LynxSecure, and Turaya Desktop are commercial examples. QubesOS, GenodeOS, and Muen Separation Kernel are open-source examples.

So, there are two things. We also have all sorts of interesting tech for protecting kernels in the works in academia that might transfer to rest of us eventually. Better virtualization (esp I/O), DIFT, CPU obfuscation, tags, capabilities, automatic safety/security transforms... you name it, there's already prototypes. So, all is not lost yet. :)

arca_vorago2• 11 years ago

Good point on the seperation kernels. I really like the team behind QubesOS, who have written some of the first evil maid articles I've read, but I haven't tried it yet. Have you used any of those systems and have an insights? Are they usable or still in the works?

Of course DoD/Darpa have their nice little distros but they tend to be proprietary and expensive so I essential pretend they don't exist for my purposes.

Thaxll2• 11 years ago

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

mhurron• 11 years ago

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

Thaxll2• 11 years ago

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

eoranged2• 11 years ago

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 automatic detection slightly harder (LOW). BTW, installing coreboot instead of manufacturer-provided firmware (if possible) also could be good improvement (PARANOID).

3. As for browser(and skype and all the rest of Internet applications) It's good thing to block and audit strange actions such as attempts to access ssh or pgp/gpg keys. By audit I mean set up quite visible and persistent notification. (MEDIUM)

4. Also, It would be great to add links to NSA Linux Configuration guide (http://www.nsa.gov/ia/mitigation_guidance/security_configura...) and CIS Security Benchmarks (http://benchmarks.cisecurity.org/downloads/browse/index.cfm?...).

wyldfire• 11 years ago

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?

eoranged2• 11 years ago

So you mean that having device with unlimited network, memory and TPM data access with encrypted firmware and separate processor should not be considered as a huge risk factor?

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.

sandworm1012• 11 years ago

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.

mricon4• 11 years ago

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

sandworm1012• 11 years ago

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.

syntheticnature• 11 years ago

Make sure you check the regs for China before modifying machines for said travel; a few years back I was supposed to head there (didn't due to a snafu), and encrypted my normal stays-at-work laptop's drive (among other measures), but it turns out that I'm not allowed to bring an encrypted device in without advance permission. Might be able to get away with it, but what happens should it be detected?

If I was going to China and really needed to bring a machine, I'd bring a Chromebook with some means to run Linux and the minimum needed to pull critical items... and it would get binned upon return, preferably without being powered up anywhere near any means to connect out (though I'd probably want to ensure it was wiped).

jqm• 11 years ago

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.

yellowapple12• 11 years ago

This is heavily dependent on hardware platform (namely, UEFI - and therefore SecureBoot, which is very foolishly being advocated given its limitations - are x86-only). While this might be acceptable for most users, this ignores that non-x86 workstations do still exist.

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.

bob1122• 11 years ago

This is very handy

Linux workstation security checklist

Related Stories