
Linux workstation security checklist - signa11
https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
======
ivank
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.

~~~
SturgeonsLaw
Not to mention this gem:

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

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

~~~
Tenhundfeld
Absolutely. I use a password manager for everything except a handful of ultra-
critical sites, mostly things involving money or attack vectors to get access
to my email. For those sites I don't trust to store in LastPass, I write the
passwords down on paper. But I also do something I haven't seen others
recommend:

 _Have a (logical) salt for all of the passwords. Don 't write down that
salt._

So, if you found my piece of paper with passwords, you might see something
like this:

Etrade - I1999IbmfsaaymIwIbmoi

Gmail - D9cjeawfocsIdkwhtfts4r

But my actual passwords are something like this:

Etrade - I1999ibmfsaaymIwibmoi804WMainStreet

Gmail - D9cjeawfocsIdkwhtfts4r804WMainStreet

804WMainStreet is tacked on to the end of all of them, but you wouldn't know
that from looking at the sheet of paper. Only my spouse knows the salt, and
it's easy for us to remember, e.g., maybe 804WMainStreet is the address of the
first place we lived together. In theory, this is reducing randomness, which
might make it easier to crack one knowing the others, but I'm not super
concerned about that.

The two most important elements of security for regular consumers are: 1) Use
different passwords for everything. 2) Use multi-factor auth when available.

Whatever you have to do to achieve that is better than not doing it.

*And I actually use initialism for these passwords so I don't have to pull out the piece of paper often, only when I forget. In this example, the Etrade password might be derived from "In 1999 I bought my first stock as a young man. I wish I bought more of it."

~~~
yellowapple
> *And I actually use initialism for these passwords so I don't have to pull
> out the piece of paper often, only when I forget. In this example, the
> Etrade password might be derived from "In 1999 I bought my first stock as a
> young man. I wish I bought more of it."

Ideally, you'd just set "In 1999 I bought my first stock as a young man. I
wish I bought more of it." as your actual password :)

~~~
Tenhundfeld
Can't really argue with that. I guess got this in habit of using initialisms,
because a lot of sites had limits of 32 characters for passwords.

But that's probably less true these days. Since they should be hashing the
password anyway, why not allow something huge, say up to 1000 characters.

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

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

~~~
Hello71
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...](http://cateee.net/lkddb/web-
lkddb/FIREWIRE_OHCI_REMOTE_DMA.html)

[1]
[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=080de8c2c57e3199eee837fe8b6d35a43679f8c1)

[2]
[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8bc588e0e585bc9085df75e84d4d5635f45cf360)

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

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

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

~~~
exceptione
I am wondering myselves too.

    
    
      The new module parameter "remote_dma" (default = N, enable
      unfiltered remote DMA = Y) replaces the former build-time 
      option CONFIG_FIREWIRE_OHCI_REMOTE_DMA. (This kernel 
      configuration option was located in the "Kernel hacking" 
      menu, item "Remote debugging over FireWire with firewire-
      ohci".) It is therefore now possible to switch on RDMA at 
      runtime on all kernels with firewire-ohci loaded or built-in, 
      for example for remote debugging, without the need for a 
      custom build option.
    

_from:[https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Lin...](https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Linux_3.14)
_

I am not an expert in these matters, but could it be that OP is wrong with
regarding to firewire? From what I am reading here is that dma is off by
default, and can only be activated at runtime.

If the OP is right about the need to disable firewire, I hope someone could
explain why so…

------
eoranged
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](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...](http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml#linux2))
and CIS Security Benchmarks
([http://benchmarks.cisecurity.org/downloads/browse/index.cfm?...](http://benchmarks.cisecurity.org/downloads/browse/index.cfm?category=benchmarks.os.linux)).

~~~
wyldfire
> 1\. TPM on recent Intel hardware is controlled by Intel Management Engine
> ([http://libreboot.org/faq/#intelme](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?

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

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

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

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

~~~
yellowapple
Historical reasons aside, some operating systems (like OpenBSD) are designed
to be able to implement different security policies by filesystem. For
example, you could mark a given filesystem as executable or non-executable,
adding yet another layer of security (at least policy-wise) to a system. And
really, with things like LVM and btrfs, there's little reason why this is a
_bad_ idea anymore, since expanding subvolumes/LVs is generally trivial.

~~~
Tiksi
You can do that in linux by bind mounting a folder to itself with the more
secure options. I have a couple systems where I do this to have directories
noexec, nosuid, etc. Kinda hackish but useful.

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

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

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

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

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

~~~
icebraining
Tarsnap now has a GUI: [https://github.com/Tarsnap/tarsnap-
gui/wiki/Tarsnap](https://github.com/Tarsnap/tarsnap-gui/wiki/Tarsnap)

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

------
oofabz
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/](http://www.fail2ban.org/)

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

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

~~~
yellowapple
Ideally, those colleagues would keep sshd disabled unless they actually do
need your remote assistance, at which point they'd "service sshd start" or
"systemctl sshd.service start" (or however it's normally done with systemd) or
"/etc/init.d/ssh start" or "/etc/rc.d/rc.ssh start" or what have you.
Minimization of attack surface is an important part of a comprehensive
security strategy, and a remote login system - even one with a phenomenal
track record like OpenSSH - contributes pretty heavily to that attack surface.

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

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

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

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

[1] Silly because, you know, closed source

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

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

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

~~~
yellowapple
If only the NSA knew that :)

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

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

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

------
616c
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?

~~~
josteink
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...](https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Secure_Boot)

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.

~~~
616c
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.

~~~
josteink
_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.

~~~
616c
I thought there was a significant gap between our views, but I think you and I
are of very similar viewpoints. Thanks for teasing something more detailed out
of me, so I do not feel like so much of a troll.

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

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

~~~
jmnicolas
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
What kind of breaches do you fear with your air-gapped setup?

~~~
jmnicolas
The Police.

------
federico3
Shameless plug: a software "checklist" for desktop users -
[https://github.com/FedericoCeratto/desktop-security-
assistan...](https://github.com/FedericoCeratto/desktop-security-assistant)

------
linuxkerneldev
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
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](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.

------
w8rbt
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](https://en.wikipedia.org/wiki/TOMOYO_Linux)

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

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

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

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

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

------
okasaki
PaX is not a MAC framework.

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

~~~
nickpsecurity
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_vorago
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.

~~~
nickpsecurity
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...](https://www.schneier.com/blog/archives/2014/04/reverse_heartbl.html#c5581737)

[2]
[https://www.schneier.com/blog/archives/2014/05/friday_squid_...](https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639)

------
bob1122
This is very handy

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

------
known
Install [http://wiki.debian.org/iptables](http://wiki.debian.org/iptables)

