Linux workstation security checklist

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

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 root shell and you never enter any passwords anywhere except the pin to unlock the yubikey's openpgp applet. The yubikey will lock the key after six unsuccessful pin attemps and you can just yank the key out when it's not being used.

Now all I need is some sort of phone app that reaches out to me on a side-channel to pops up asking me to authorize each login (something like libpam-askmeonmyphone)--(I really like the way the Microsoft Account 2FA phone app works in this regard). If I could change one thing about the yubikey neo, it's that I'd require it to make me physically interact with it to decrypt anything (beyond entering the PIN).

I agree with you. I had to design some concepts for securing a boot process or replacing BIOS. My first inspirations were Open Firmware, Coreboot, and U-Boot, already doing much of the job. However, all too complicated, incomplete, or Forthy. So, I saw it from three basic angles drawing on what was done in past:

1. Replaceable ROM or read-only, flash chip that the system booted from with open-spec for user customization. You can trust their bootloader, yours, etc. Modifications require physical replacement to avoid software attacks. You can know what it's doing because you can flash it yourself or use your own if it's physically compatible. Can be cheap. Simple.

2. Combination of anti-fuse ROM and flash. The ROM has a highly robust firmware that test chip, initializes some stuff, pulls firmware out of flash, does crypto checks on it, and then runs it. In a maintenance or update mode, the ROM + flash combo can pull up an upgrade into memory, disable all I/O that can affect it, check it, flash it into storage, and reboot. ROM can't be modified without physical replacement, so always a root of trust to start with. Can be combined with No 1 if necessary.

3. Software-only protection necessitates combating 0-days. This means gotta use an EAL6+ development process. Abstract away hardware details into functions with interface types and checks. Code in safe subset with static analysis, testing, and simulation. Make different device handling pluggable modules to run that interact with safe interface. Extract implementation from that. Examples include using SPARK Ada, MISRA C w/ ASTREE checker, or Java via BootSafe technology. Optionally auto-gen tech like Termite for drivers.

Personally, I think we could go with No 1 on everything down to laptops and some tablets. Ultra-compact things such as smartphones can use No 2. No 3 is only for the most stubborn, cost-sensitive companies and those are unfortunately least likely to go the extra mile lol.

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

QubesOS founder and I got into it on their mailing list so I haven't tried it. Joanna updated her blog and FAQ to try to counter every point without mentioning my name or allowing replies lol. Anyway, my worries were: the Dom0 code in TCB, Xen kernel's complexity plus bug count, no covert channel analysis, that she was unaware of all similar research/issues in that area before Qubes, that she didn't know why user-mode drivers improved system robustness, and that she cited Mach/Darwin as why microkernels like L4 weren't good foundations (?!). All troubling traits if I'm to trust what they produce against High-Strength Attackers. However, my friends that have tried it like it, praise the usability, and say (with backups) you could use it day-to-day. So, I recommend it along the same vein as whitelisting and anti-virus: stops low to mid-grade attackers along with background radiation of Internet.

Plan to try all three again soon. Muen is a straight separation kernel with static configuration. So, will be limited but usable for simple setups: appliances, trusted + untrusted VM's, main stuff in Linux w/ crypto stuff in OBSD or native partition, maybe embedded on decent hardware, etc. GenodeOS is getting rapid development for a small project with a clever, resource-management architecture that needs further evaluation by pro's. Unlike QubesOS, they follow academic work producing best-of-breed components (eg Nitpicker GUI, seL4) and try to integrate them. Project itself was result of work to make more secure architecture. Both of prior have tiny TCB w/ GenodeOS having microkernel's performance advantages (Muen situation unknown). Finally, QubesOS builds some nice architecture, excellent usability, and hardening on top of mature Xen code-base with its risks/rewards. So, not really apples to apples here with any of them. QubesOS is definitely ahead in usability and features, though.

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

That's true. You have to pay to get the really good shit. OSS/FLOSS never do [1] high-assurance security, though: almost always companies or academia releasing it OSS after the fact. So, I've been investigating models that combine open-source, proprietary licensing, and review. If that's a shock, it's because almost all online discussions talk either proprietary/closed or free/open. However, that's barely relevant for security in practice and narrow thinking that misses other options [2]. So, my idea is to make the software proprietary, optionally a non-profit, have pro's build it for money, put an upper bounds on licensing cost, keep purchases perpetual, simple contract terms that won't change, source provided, extensions allowed with re-submission requirements yet to be determined, paid review by pro's, rewards to encourage others, and contractually to be released Apache/GPL if company tanks or product to be discontinued. This should cover extreme sophistication and labor required to build high-security, let people extend, let people fix stuff, and being more trustworthy. Your thoughts?

[1] https://www.schneier.com/blog/archives/2014/04/reverse_heart...

[2] https://www.schneier.com/blog/archives/2014/05/friday_squid_...