From cbe0470402a2ef2303db565a5a3475d50643f9c1 Mon Sep 17 00:00:00 2001 From: DeadFire <wxj@cnite.net> Date: Mon, 31 Aug 2015 16:12:20 +0800 Subject: [PATCH] =?UTF-8?q?20150831-1=20=E9=80=89=E9=A2=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...31 Linux workstation security checklist.md | 800 ++++++++++++++++++ 1 file changed, 800 insertions(+) create mode 100644 sources/tech/20150831 Linux workstation security checklist.md diff --git a/sources/tech/20150831 Linux workstation security checklist.md b/sources/tech/20150831 Linux workstation security checklist.md new file mode 100644 index 0000000000..bc2b59f16a --- /dev/null +++ b/sources/tech/20150831 Linux workstation security checklist.md @@ -0,0 +1,800 @@ +Linux workstation security checklist +================================================================================ +This is a set of recommendations used by the Linux Foundation for their systems +administrators. All of LF employees are remote workers and we use this set of +guidelines to ensure that a sysadmin's system passes core security requirements +in order to reduce the risk of it becoming an attack vector against the rest +of our infrastructure. + +Even if your systems administrators are not remote workers, chances are that +they perform a lot of their work either from a portable laptop in a work +environment, or set up their home systems to access the work infrastructure +for after-hours/emergency support. In either case, you can adapt this set of +recommendations to suit your environment. + +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. You may read this +document and think it is way too paranoid, while someone else may think this +barely scratches the surface. Security is just like driving on the highway -- +anyone going slower than you is an idiot, while anyone driving faster than you +is a crazy person. These guidelines are merely a basic set of core safety +rules that is neither exhaustive, nor a replacement for experience, vigilance, +and common sense. + +Each section is split into two areas: + +- The checklist that can be adapted to your project's needs +- Free-form list of considerations that explain what dictated these decisions + +## Severity levels + +The items in each checklist include the severity level, which we hope will help +guide your decision: + +- _(CRITICAL)_ items should definitely be high on the consideration list. + If not implemented, they will introduce high risks to your workstation + security. +- _(MODERATE)_ items will improve your security posture, but are less + important, especially if they interfere too much with your workflow. +- _(LOW)_ items may improve the overall security, but may not be worth the + convenience trade-offs. +- _(PARANOID)_ is reserved for items we feel will dramatically improve your + workstation security, but will probably require a lot of adjustment to the + way you interact with your operating system. + +Remember, these are only guidelines. If you feel these severity levels do not +reflect your project's commitment to security, you should adjust them as you +see fit. + +## Choosing the right hardware + +We do not mandate that our admins use a specific vendor or a specific model, so +this section addresses core considerations when choosing a work system. + +### Checklist + +- [ ] System supports SecureBoot _(CRITICAL)_ +- [ ] System has no firewire, thunderbolt or ExpressCard ports _(MODERATE)_ +- [ ] System has a TPM chip _(LOW)_ + +### Considerations + +#### SecureBoot + +Despite its controversial nature, SecureBoot offers prevention against many +attacks targeting workstations (Rootkits, "Evil Maid," etc), without +introducing too much extra hassle. It will not stop a truly dedicated attacker, +plus there is a pretty high degree of certainty that state security agencies +have ways to defeat it (probably by design), but having SecureBoot is better +than having nothing at all. + +Alternatively, you may set up [Anti Evil Maid][1] which offers a more +wholesome protection against the type of attacks that SecureBoot is supposed +to prevent, but it will require more effort to set up and maintain. + +#### Firewire, thunderbolt, and ExpressCard ports + +Firewire is a standard that, by design, allows any connecting device full +direct memory access to your system ([see Wikipedia][2]). Thunderbolt and +ExpressCard are guilty of the same, though some later implementations of +Thunderbolt attempt to limit the scope of memory access. It is best if the +system you are getting has none of these ports, but it is not critical, as +they usually can be turned off via UEFI or disabled in the kernel itself. + +#### TPM Chip + +Trusted Platform Module (TPM) is a crypto chip bundled with the motherboard +separately from the core processor, which can be used for additional platform +security (such as to store full-disk encryption keys), but is not normally used +for day-to-day workstation operation. At best, this is a nice-to-have, unless +you have a specific need to use TPM for your workstation security. + +## Pre-boot environment + +This is a set of recommendations for your workstation before you even start +with OS installation. + +### Checklist + +- [ ] UEFI boot mode is used (not legacy BIOS) _(CRITICAL)_ +- [ ] Password is required to enter UEFI configuration _(CRITICAL)_ +- [ ] SecureBoot is enabled _(CRITICAL)_ +- [ ] UEFI-level password is required to boot the system _(LOW)_ + +### Considerations + +#### UEFI and SecureBoot + +UEFI, with all its warts, offers a lot of goodies that legacy BIOS doesn't, +such as SecureBoot. Most modern systems come with UEFI mode on by default. + +Make sure a strong password is required to enter UEFI configuration mode. Pay +attention, as many manufacturers quietly limit the length of the password you +are allowed to use, so you may need to choose high-entropy short passwords vs. +long passphrases (see below for more on passphrases). + +Depending on the Linux distribution you decide to use, you may or may not have +to jump through additional hoops in order to import your distribution's +SecureBoot key that would allow you to boot the distro. Many distributions have +partnered with Microsoft to sign their released kernels with a key that is +already recognized by most system manufacturers, therefore saving you the +trouble of having to deal with key importing. + +As an extra measure, before someone is allowed to even get to the boot +partition and try some badness there, let's make them enter a password. This +password should be different from your UEFI management password, in order to +prevent shoulder-surfing. If you shut down and start a lot, you may choose to +not bother with this, as you will already have to enter a LUKS passphrase and +this will save you a few extra keystrokes. + +## Distro choice considerations + +Chances are you'll stick with a fairly widely-used distribution such as Fedora, +Ubuntu, Arch, Debian, or one of their close spin-offs. In any case, this is +what you should consider when picking a distribution to use. + +### Checklist + +- [ ] Has a robust MAC/RBAC implementation (SELinux/AppArmor/Grsecurity) _(CRITICAL)_ +- [ ] Publishes security bulletins _(CRITICAL)_ +- [ ] Provides timely security patches _(CRITICAL)_ +- [ ] Provides cryptographic verification of packages _(CRITICAL)_ +- [ ] Fully supports UEFI and SecureBoot _(CRITICAL)_ +- [ ] Has robust native full disk encryption support _(CRITICAL)_ + +### Considerations + +#### SELinux, AppArmor, and GrSecurity/PaX + +Mandatory Access Controls (MAC) or Role-Based Access Controls (RBAC) are an +extension of the basic user/group security mechanism used in legacy POSIX +systems. Most distributions these days either already come bundled with a +MAC/RBAC implementation (Fedora, Ubuntu), or provide a mechanism to add it via +an optional post-installation step (Gentoo, Arch, Debian). Obviously, it is +highly advised that you pick a distribution that comes pre-configured with a +MAC/RBAC system, but if you have strong feelings about a distribution that +doesn't have one enabled by default, do plan to configure it +post-installation. + +Distributions that do not provide any MAC/RBAC mechanisms should be strongly +avoided, as traditional POSIX user- and group-based security should be +considered insufficient in this day and age. If you would like to start out +with a MAC/RBAC workstation, AppArmor and PaX are generally considered easier +to learn than SELinux. Furthermore, on a workstation, where there are few or +no externally listening daemons, and where user-run applications pose the +highest risk, GrSecurity/PaX will _probably_ offer more security benefits than +SELinux. + +#### Distro security bulletins + +Most of the widely used distributions have a mechanism to deliver security +bulletins to their users, but if you are fond of something esoteric, check +whether the developers have a documented mechanism of alerting the users about +security vulnerabilities and patches. Absence of such mechanism is a major +warning sign that the distribution is not mature enough to be considered for a +primary admin workstation. + +#### Timely and trusted security updates + +Most of the widely used distributions deliver regular security updates, but is +worth checking to ensure that critical package updates are provided in a +timely fashion. Avoid using spin-offs and "community rebuilds" for this +reason, as they routinely delay security updates due to having to wait for the +upstream distribution to release it first. + +You'll be hard-pressed to find a distribution that does not use cryptographic +signatures on packages, updates metadata, or both. That being said, fairly +widely used distributions have been known to go for years before introducing +this basic security measure (Arch, I'm looking at you), so this is a thing +worth checking. + +#### Distros supporting UEFI and SecureBoot + +Check that the distribution supports UEFI and SecureBoot. Find out whether it +requires importing an extra key or whether it signs its boot kernels with a key +already trusted by systems manufacturers (e.g. via an agreement with +Microsoft). Some distributions do not support UEFI/SecureBoot but offer +alternatives to ensure tamper-proof or tamper-evident boot environments +([Qubes-OS][3] uses Anti Evil Maid, mentioned earlier). If a distribution +doesn't support SecureBoot and has no mechanisms to prevent boot-level attacks, +look elsewhere. + +#### Full disk encryption + +Full disk encryption is a requirement for securing data at rest, and is +supported by most distributions. As an alternative, systems with +self-encrypting hard drives may be used (normally implemented via the on-board +TPM chip) and offer comparable levels of security plus faster operation, but at +a considerably higher cost. + +## Distro installation guidelines + +All distributions are different, but here are general guidelines: + +### Checklist + +- [ ] Use full disk encryption (LUKS) with a robust passphrase _(CRITICAL)_ +- [ ] Make sure swap is also encrypted _(CRITICAL)_ +- [ ] Require a password to edit bootloader (can be same as LUKS) _(CRITICAL)_ +- [ ] Set up a robust root password (can be same as LUKS) _(CRITICAL)_ +- [ ] Use an unprivileged account, part of administrators group _(CRITICAL)_ +- [ ] Set up a robust user-account password, different from root _(CRITICAL)_ + +### Considerations + +#### Full disk encryption + +Unless you are using self-encrypting hard drives, it is important to configure +your installer to fully encrypt all the disks that will be used for storing +your data and your system files. It is not sufficient to simply encrypt the +user directory via auto-mounting cryptfs loop files (I'm looking at you, older +versions of Ubuntu), as this offers no protection for system binaries or swap, +which is likely to contain a slew of sensitive data. The recommended +encryption strategy is to encrypt the LVM device, so only one passphrase is +required during the boot process. + +The `/boot` partition will always remain unencrypted, as the bootloader needs +to be able to actually boot the kernel before invoking LUKS/dm-crypt. The +kernel image itself should be protected against tampering with a cryptographic +signature checked by SecureBoot. + +In other words, `/boot` should always be the only unencrypted partition on your +system. + +#### Choosing good passphrases + +Modern Linux systems have no limitation of password/passphrase length, so the +only real limitation is your level of paranoia and your stubbornness. If you +boot your system a lot, you will probably have to type at least two different +passwords: one to unlock LUKS, and another one to log in, so having long +passphrases will probably get old really fast. Pick passphrases that are 2-3 +words long, easy to type, and preferably from rich/mixed vocabularies. + +Examples of good passphrases (yes, you can use spaces): +- nature abhors roombas +- 12 in-flight Jebediahs +- perdon, tengo flatulence + +You can also stick with non-vocabulary passwords that are at least 10-12 +characters long, if you prefer that to typing passphrases. + +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. + +#### Root, user passwords and the admin group + +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. Generally, you can use the same passphrase for your UEFI +administration, disk encryption, and root account -- knowing any of these will +give an attacker full control of your system anyway, so there is little +security benefit to have them be different on a single-user workstation. + +You should have a different, but equally strong password for your regular user +account that you will be using for day-to-day tasks. This user should be member +of the admin group (e.g. `wheel` or similar, depending on the distribution), +allowing you to perform `sudo` to elevate privileges. + +In other words, if you are the sole user on your workstation, you should have 2 +distinct, robust, equally strong passphrases you will need to remember: + +**Admin-level**, used in the following locations: + +- UEFI administration +- Bootloader (GRUB) +- Disk encryption (LUKS) +- Workstation admin (root user) + +**User-level**, used for the following: + +- User account and sudo +- Master password for the password manager + +All of them, obviously, can be different if there is a compelling reason. + +## Post-installation hardening + +Post-installation security hardening will depend greatly on your distribution +of choice, so it is futile to provide detailed instructions in a general +document such as this one. However, here are some steps you should take: + +### Checklist + +- [ ] Globally disable firewire and thunderbolt modules _(CRITICAL)_ +- [ ] Check your firewalls to ensure all incoming ports are filtered _(CRITICAL)_ +- [ ] Make sure root mail is forwarded to an account you check _(CRITICAL)_ +- [ ] Check to ensure sshd service is disabled by default _(MODERATE)_ +- [ ] Set up an automatic OS update schedule, or update reminders _(MODERATE)_ +- [ ] Configure the screensaver to auto-lock after a period of inactivity _(MODERATE)_ +- [ ] Set up logwatch _(MODERATE)_ +- [ ] Install and use rkhunter _(LOW)_ +- [ ] Install an Intrusion Detection System _(PARANOID)_ + +### Considerations + +#### Blacklisting modules + +To blacklist a firewire and thunderbolt modules, add the following lines to a +file in `/etc/modprobe.d/blacklist-dma.conf`: + + blacklist firewire-core + blacklist thunderbolt + +The modules will be blacklisted upon reboot. It doesn't hurt doing this even if +you don't have these ports (but it doesn't do anything either). + +#### Root mail + +By default, root mail is just saved on the system and tends to never be read. +Make sure you set your `/etc/aliases` to forward root mail to a mailbox that +you actually read, otherwise you may miss important system notifications and +reports: + + # Person who should get root's mail + root: bob@example.com + +Run `newaliases` after this edit and test it out to make sure that it actually +gets delivered, as some email providers will reject email coming in from +nonexistent or non-routable domain names. If that is the case, you will need to +play with your mail forwarding configuration until this actually works. + +#### Firewalls, sshd, and listening daemons + +The default firewall settings will depend on your distribution, but many of +them will allow incoming `sshd` ports. Unless you have a compelling legitimate +reason to allow incoming ssh, you should filter that out and disable the `sshd` +daemon. + + systemctl disable sshd.service + systemctl stop sshd.service + +You can always start it temporarily if you need to use it. + +In general, your system shouldn't have any listening ports apart from +responding to ping. This will help safeguard you against network-level 0-day +exploits. + +#### Automatic updates or notifications + +It is recommended to turn on automatic updates, unless you have a very good +reason not to do so, such as fear that an automatic update would render your +system unusable (it's happened in the past, so this fear is not unfounded). At +the very least, you should enable automatic notifications of available updates. +Most distributions already have this service automatically running for you, so +chances are you don't have to do anything. Consult your distribution +documentation to find out more. + +You should apply all outstanding errata as soon as possible, even if something +isn't specifically labeled as "security update" or has an associated CVE code. +All bugs have the potential of being security bugs and erring on the side of +newer, unknown bugs is _generally_ a safer strategy than sticking with old, +known ones. + +#### Watching logs + +You should have a keen interest in what happens on your system. For this +reason, you should install `logwatch` and configure it to send nightly activity +reports of everything that happens on your system. This won't prevent a +dedicated attacker, but is a good safety-net feature to have in place. + +Note, that many systemd distros will no longer automatically install a syslog +server that `logwatch` needs (due to systemd relying on its own journal), so +you will need to install and enable `rsyslog` to make sure your `/var/log` is +not empty before logwatch will be of any use. + +#### Rkhunter and IDS + +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 (such as, keeping the +databases on external media, running checks from a trusted environment, +remembering to refresh the hash databases after performing system updates and +configuration changes, etc). If you are not willing to take these steps and +adjust how you do things on your own workstation, these tools will introduce +hassle without any tangible security benefit. + +We do recommend that you install `rkhunter` and run it nightly. It's fairly +easy to learn and use, and though it will not deter a sophisticated attacker, +it may help you catch your own mistakes. + +## Personal workstation backups + +Workstation backups tend to be overlooked or done in a haphazard, often unsafe +manner. + +### Checklist + +- [ ] Set up encrypted workstation backups to external storage _(CRITICAL)_ +- [ ] Use zero-knowledge backup tools for cloud backups _(MODERATE)_ + +### Considerations + +#### Full encrypted backups to external storage + +It is handy to have an external hard drive where one can dump full backups +without having to worry about such things like bandwidth and upstream speeds +(in this day and age most providers still offer dramatically asymmetric +upload/download speeds). Needless to say, this hard drive needs to be in itself +encrypted (again, via LUKS), or you should use a backup tool that creates +encrypted backups, such as `duplicity` or its GUI companion, `deja-dup`. I +recommend using the latter with a good randomly generated passphrase, stored in +your password manager. If you travel with your laptop, leave this drive at home +to have something to come back to in case your laptop is lost or stolen. + +In addition to your home directory, you should also back up `/etc` and +`/var/log` for various forensic purposes. + +Above all, avoid copying your home directory onto any unencrypted storage, even +as a quick way to move your files around between systems, as you will most +certainly forget to erase it once you're done, exposing potentially private or +otherwise security sensitive data to snooping hands -- especially if you keep +that storage media in the same bag with your laptop. + +#### Selective zero-knowledge backups off-site + +Off-site backups are also extremely important and can be done either to your +employer, if they offer space for it, or to a cloud provider. You can set up a +separate duplicity/deja-dup profile to only include most important files in +order to avoid transferring huge amounts of data that you don't really care to +back up off-site (internet cache, music, downloads, etc). + +Alternatively, you can use a zero-knowledge backup tool, such as +[SpiderOak][5], which offers an excellent Linux GUI tool and has additional +useful features such as synchronizing content between multiple systems and +platforms. + +## Best practices + +What follows is a curated list of best practices that we think you should +adopt. It is most certainly non-exhaustive, but rather attempts to offer +practical advice that strikes a workable balance between security and overall +usability. + +### Browsing + +There is no question that the web browser will be the piece of software with +the largest and the most exposed attack surface on your system. It is a tool +written specifically to download and execute untrusted, frequently hostile +code. It attempts to shield you from this danger by employing multiple +mechanisms such as sandboxes and code sanitization, but they have all been +previously defeated on multiple occasions. You should learn to approach +browsing websites as the most insecure activity you'll engage in on any given +day. + +There are several ways you can reduce the impact of a compromised browser, but +the truly effective ways will require significant changes in the way you +operate your workstation. + +#### 1: Use two different browsers + +This is the easiest to do, but only offers minor security benefits. Not all +browser compromises give an attacker full unfettered access to your system -- +sometimes they are limited to allowing one to read local browser storage, +steal active sessions from other tabs, capture input entered into the browser, +etc. Using two different browsers, one for work/high security sites, and +another for everything else will help prevent minor compromises from giving +attackers access to the whole cookie jar. The main inconvenience will be the +amount of memory consumed by two different browser processes. + +Here's what we recommend: + +##### Firefox for work and high security sites + +Use Firefox to access work-related sites, where extra care should be taken to +ensure that data like cookies, sessions, login information, keystrokes, etc, +should most definitely not fall into attackers' hands. You should NOT use +this browser for accessing any other sites except select few. + +You should install the following Firefox add-ons: + +- [ ] NoScript _(CRITICAL)_ + - NoScript prevents active content from loading, except from user + whitelisted domains. It is a great hassle to use with your default browser + (though offers really good security benefits), so we recommend only + enabling it on the browser you use to access work-related sites. + +- [ ] Privacy Badger _(CRITICAL)_ + - EFF's Privacy Badger will prevent most external trackers and ad platforms + from being loaded, which will help avoid compromises on these tracking + sites from affecting your browser (trackers and ad sites are very commonly + targeted by attackers, as they allow rapid infection of thousands of + systems worldwide). + +- [ ] HTTPS Everywhere _(CRITICAL)_ + - This EFF-developed Add-on will ensure that most of your sites are accessed + over a secure connection, even if a link you click is using http:// (great + to avoid a number of attacks, such as [SSL-strip][7]). + +- [ ] Certificate Patrol _(MODERATE)_ + - This tool will alert you if the site you're accessing has recently changed + their TLS certificates -- especially if it wasn't nearing expiration dates + or if it is now using a different certification authority. It helps + alert you if someone is trying to man-in-the-middle your connection, + but generates a lot of benign false-positives. + +You should leave Firefox as your default browser for opening links, as +NoScript will prevent most active content from loading or executing. + +##### Chrome/Chromium for everything else + +Chromium developers are ahead of Firefox in adding a lot of nice security +features (at least [on Linux][6]), such as seccomp sandboxes, kernel user +namespaces, etc, which act as an added layer of isolation between the sites +you visit and the rest of your system. Chromium is the upstream open-source +project, and Chrome is Google's proprietary binary build based on it (insert +the usual paranoid caution about not using it for anything you don't want +Google to know about). + +It is recommended that you install **Privacy Badger** and **HTTPS Everywhere** +extensions in Chrome as well and give it a distinct theme from Firefox to +indicate that this is your "untrusted sites" browser. + +#### 2: Use two different browsers, one inside a dedicated VM + +This is a similar recommendation to the above, except you will add an extra +step of running Chrome inside a dedicated VM that you access via a fast +protocol, allowing you to share clipboards and forward sound events (e.g. +Spice or RDP). This will add an excellent layer of isolation between the +untrusted browser and the rest of your work environment, ensuring that +attackers who manage to fully compromise your browser will then have to +additionally break out of the VM isolation layer in order to get to the rest +of your system. + +This is a surprisingly workable configuration, but requires a lot of RAM and +fast processors that can handle the increased load. It will also require an +important amount of dedication on the part of the admin who will need to +adjust their work practices accordingly. + +#### 3: Fully separate your work and play environments via virtualization + +See [Qubes-OS project][3], which strives to provide a high-security +workstation environment via compartmentalizing your applications into separate +fully isolated VMs. + +### Password managers + +#### Checklist + +- [ ] Use a password manager _(CRITICAL_) +- [ ] Use unique passwords on unrelated sites _(CRITICAL)_ +- [ ] Use a password manager that supports team sharing _(MODERATE)_ +- [ ] Use a separate password manager for non-website accounts _(PARANOID)_ + +#### Considerations + +Using good, unique passwords should be a critical requirement for every member +of your team. Credential theft is happening all the time -- either via +compromised computers, stolen database dumps, remote site exploits, or any +number of other means. No credentials should ever be reused across sites, +especially for critical applications. + +##### In-browser password manager + +Every browser has a mechanism for saving passwords that is fairly secure and +can sync with vendor-maintained cloud storage while keeping the data encrypted +with a user-provided passphrase. However, this mechanism has important +disadvantages: + +1. It does not work across browsers +2. It does not offer any way of sharing credentials with team members + +There are several well-supported, free-or-cheap password managers that are +well-integrated into multiple browsers, work across platforms, and offer +group sharing (usually as a paid service). Solutions can be easily found via +search engines. + +##### Standalone password manager + +One of the major drawbacks of any password manager that comes integrated with +the browser is the fact that it's part of the application that is most likely +to be attacked by intruders. If this makes you uncomfortable (and it should), +you may choose to have two different password managers -- one for websites +that is integrated into your browser, and one that runs as a standalone +application. The latter can be used to store high-risk credentials such as +root passwords, database passwords, other shell account credentials, etc. + +It may be particularly useful to have such tool for sharing superuser account +credentials with other members of your team (server root passwords, ILO +passwords, database admin passwords, bootloader passwords, etc). + +A few tools can help you: + +- [KeePassX][8], which improves team sharing in version 2 +- [Pass][9], which uses text files and PGP and integrates with git +- [Django-Pstore][10], which uses GPG to share credentials between admins +- [Hiera-Eyaml][11], which, if you are already using Puppet for your + infrastructure, may be a handy way to track your server/service credentials + as part of your encrypted Hiera data store + +### Securing SSH and PGP private keys + +Personal encryption keys, including SSH and PGP private keys, are going to be +the most prized items on your workstation -- something the attackers will be +most interested in obtaining, as that would allow them to further attack your +infrastructure or impersonate you to other admins. You should take extra steps +to ensure that your private keys are well protected against theft. + +#### Checklist + +- [ ] Strong passphrases are used to protect private keys _(CRITICAL)_ +- [ ] PGP Master key is stored on removable storage _(MODERATE)_ +- [ ] Auth, Sign and Encrypt Subkeys are stored on a smartcard device _(MODERATE)_ +- [ ] SSH is configured to use PGP Auth key as ssh private key _(MODERATE)_ + +#### Considerations + +The best way to prevent private key theft is to use a smartcard to store your +encryption private keys and never copy them onto the workstation. There are +several manufacturers that offer OpenPGP capable devices: + +- [Kernel Concepts][12], where you can purchase both the OpenPGP compatible + smartcards and the USB readers, should you need one. +- [Yubikey NEO][13], which offers OpenPGP smartcard functionality in addition + to many other cool features (U2F, PIV, HOTP, etc). + +It is also important to make sure that the master PGP key is not stored on the +main workstation, and only subkeys are used. The master key will only be +needed when signing someone else's keys or creating new subkeys -- operations +which do not happen very frequently. You may follow [the Debian's subkeys][14] +guide to learn how to move your master key to removable storage and how to +create subkeys. + +You should then configure your gnupg agent to act as ssh agent and use the +smartcard-based PGP Auth key to act as your ssh private key. We publish a +[detailed guide][15] on how to do that using either a smartcard reader or a +Yubikey NEO. + +If you are not willing to go that far, at least make sure you have a strong +passphrase on both your PGP private key and your SSH private key, which will +make it harder for attackers to steal and use them. + +### SELinux on the workstation + +If you are using a distribution that comes bundled with SELinux (such as +Fedora), here are some recommendation of how to make the best use of it to +maximize your workstation security. + +#### Checklist + +- [ ] Make sure SELinux is enforcing on your workstation _(CRITICAL)_ +- [ ] Never blindly run `audit2allow -M`, always check _(CRITICAL)_ +- [ ] Never `setenforce 0` _(MODERATE)_ +- [ ] Switch your account to SELinux user `staff_u` _(MODERATE)_ + +#### Considerations + +SELinux is a Mandatory Access Controls (MAC) extension to core POSIX +permissions functionality. It is mature, robust, and has come a long way since +its initial roll-out. Regardless, many sysadmins to this day repeat the +outdated mantra of "just turn it off." + +That being said, SELinux will have limited security benefits on the +workstation, as most applications you will be running as a user are going to +be running unconfined. It does provide enough net benefit to warrant leaving +it on, as it will likely help prevent an attacker from escalating privileges +to gain root-level access via a vulnerable daemon service. + +Our recommendation is to leave it on and enforcing. + +##### Never `setenforce 0` + +It's tempting to use `setenforce 0` to flip SELinux into permissive mode +on a temporary basis, but you should avoid doing that. This essentially turns +off SELinux for the entire system, while what you really want is to +troubleshoot a particular application or daemon. + +Instead of `setenforce 0` you should be using `semanage permissive -a +[somedomain_t]` to put only that domain into permissive mode. First, find out +which domain is causing troubles by running `ausearch`: + + ausearch -ts recent -m avc + +and then look for `scontext=` (source SELinux context) line, like so: + + scontext=staff_u:staff_r:gpg_pinentry_t:s0-s0:c0.c1023 + ^^^^^^^^^^^^^^ + +This tells you that the domain being denied is `gpg_pinentry_t`, so if you +want to troubleshoot the application, you should add it to permissive domains: + + semange permissive -a gpg_pinentry_t + +This will allow you to use the application and collect the rest of the AVCs, +which you can then use in conjunction with `audit2allow` to write a local +policy. Once that is done and you see no new AVC denials, you can remove that +domain from permissive by running: + + semanage permissive -d gpg_pinentry_t + +##### Use your workstation as SELinux role staff_r + +SELinux comes with a native implementation of roles that prohibit or grant +certain privileges based on the role associated with the user account. As an +administrator, you should be using the `staff_r` role, which will restrict +access to many configuration and other security-sensitive files, unless you +first perform `sudo`. + +By default, accounts are created as `unconfined_r` and most applications you +execute will run unconfined, without any (or with only very few) SELinux +constraints. To switch your account to the `staff_r` role, run the following +command: + + usermod -Z staff_u [username] + +You should log out and log back in to enable the new role, at which point if +you run `id -Z`, you'll see: + + staff_u:staff_r:staff_t:s0-s0:c0.c1023 + +When performing `sudo`, you should remember to add an extra flag to tell +SELinux to transition to the "sysadmin" role. The command you want is: + + sudo -i -r sysadm_r + +At which point `id -Z` will show: + + staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 + +**WARNING**: you should be comfortable using `ausearch` and `audit2allow` +before you make this switch, as it's possible some of your applications will +no longer work when you're running as role `staff_r`. At the time of writing, +the following popular applications are known to not work under `staff_r` +without policy tweaks: + +- Chrome/Chromium +- Skype +- VirtualBox + +To switch back to `unconfined_r`, run the following command: + + usermod -Z unconfined_u [username] + +and then log out and back in to get back into the comfort zone. + +## Further reading + +The world of IT security is a rabbit hole with no bottom. If you would like to +go deeper, or find out more about security features on your particular +distribution, please check out the following links: + +- [Fedora Security Guide](https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/index.html) +- [CESG Ubuntu Security Guide](https://www.gov.uk/government/publications/end-user-devices-security-guidance-ubuntu-1404-lts) +- [Debian Security Manual](https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) +- [Arch Linux Security Wiki](https://wiki.archlinux.org/index.php/Security) +- [Mac OSX Security](https://www.apple.com/support/security/guides/) + +## License +This work is licensed under a +[Creative Commons Attribution-ShareAlike 4.0 International License][0]. + +-------------------------------------------------------------------------------- + +via: https://github.com/lfit/itpol/blob/master/linux-workstation-security.md#linux-workstation-security-checklist + +作者：[mricon][a] +译者：[译者ID](https://github.com/译者ID) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://github.com/mricon +[0]: http://creativecommons.org/licenses/by-sa/4.0/ +[1]: https://github.com/QubesOS/qubes-antievilmaid +[2]: https://en.wikipedia.org/wiki/IEEE_1394#Security_issues +[3]: https://qubes-os.org/ +[4]: https://xkcd.com/936/ +[5]: https://spideroak.com/ +[6]: https://code.google.com/p/chromium/wiki/LinuxSandboxing +[7]: http://www.thoughtcrime.org/software/sslstrip/ +[8]: https://keepassx.org/ +[9]: http://www.passwordstore.org/ +[10]: https://pypi.python.org/pypi/django-pstore +[11]: https://github.com/TomPoulton/hiera-eyaml +[12]: http://shop.kernelconcepts.de/ +[13]: https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ +[14]: https://wiki.debian.org/Subkeys +[15]: https://github.com/lfit/ssh-gpg-smartcard-config \ No newline at end of file