https://wiki.archlinux.org/api.php?action=feedcontributions&user=Thestinger&feedformat=atomArchWiki - User contributions [en]2024-03-19T10:00:54ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Security&diff=735815Security2022-07-01T01:42:15Z<p>Thestinger: /* Memory */ man-db compatibility with hardened_malloc was fixed in man-db upstream</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[de:Sicherheit]]<br />
[[es:Security]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[pt:Security]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|Arch package guidelines/Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten security to the point where the system is unusable. Security and convenience must be balanced. The trick is to create a secure ''and'' useful system.<br />
* The biggest threat is, and will always be, the user.<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: Each part of a system should only be able to access what is strictly required, and nothing more.<br />
* Defense in depth: Security works better in independent layers. When one layer is breached, another should stop the attack.<br />
* Be a little paranoid. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* You can never make a system 100% secure unless you unplug the machine from all networks, turn it off, lock it in a safe, smother it in concrete and never use it.<br />
* Prepare for failure. Create a plan ahead of time to follow when your security is broken.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Data-at-rest encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
Passwords must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like social engineering or brute-force attacks. The tenets of strong passwords are based on ''length'' and ''randomness''. In cryptography the quality of a password is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}}), as modern dictionary attacks can easily work with these<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short strings of dictionary words (e.g. {{ic|photocopyhauntbranchexpose}}) including with character substitution (e.g. {{ic|Ph0toc0pyh4uN7br@nch3xp*se}}) <br />
* Any of the [[wikipedia:List_of_the_most_common_passwords|most common passwords]]<br />
<br />
The best choice for a password is something long (the longer, the better) and generated from a random source. It is important to use a long password. [https://www.theregister.com/2019/02/14/password_length Weak hash algorithms allow an 8-character password hash to be compromised in just a few hours.]<br />
<br />
Tools like {{Pkg|pwgen}} or {{AUR|apg}} can generate random passwords. However, these passwords can be difficult to memorize. One memorization technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
Apart from password management, {{Pkg|keepassxc}} offers password/passphrase generation. It is possible to customize the generation in a GUI. Dictionary based passphrases are also supported.<br />
<br />
One technique for memorizing a password is to use a mnemonic phrase, where each word in the phrase reminds you of the next character in the password.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). <br />
<br />
Another effective technique can be to write randomly generated passwords down and store them in a ''safe'' place, such as in a wallet, purse or document safe. Most people do a generally good job of protecting their physical valuables from attack, and it is easier for most people to understand physical security best practices compared to digital security practices.<br />
<br />
It is also very effective to combine the mnemonic and random technique by saving long randomly generated passwords with a [[password manager]], which will be in turn accessed with a memorable "master password" that must be used only for that purpose. The master password must be memorized and never saved. This requires the password manager to be installed on a system to easily access the password (which could be seen as an inconvenience or a security feature, depending on the situation). Some password managers also have smartphone apps which can be used to display passwords for manual entry on systems without that password manager installed. Note that a password manager introduces a single point of failure if you ever forget the master password.<br />
<br />
It can be effective to use a memorable long series of unrelated words as a password. The theory is that if a sufficiently long phrase is used, the gained entropy from the password's length can counter the lost entropy from the use of dictionary words. This [https://xkcd.com/936/ xkcd comic] demonstrates the entropy tradeoff of this method, taking into account the limited set of possible words for each word in the passphrase. If the set of words you choose from is large (multiple thousand words) and you choose 5-7 or even more random words from it, this method provides great entropy, even assuming the attacker knows the set of possible words chosen from and the number of words chosen. See e.g. [https://www.rempe.us/diceware/ Diceware] for more.<br />
<br />
See [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), screen loggers, [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}). Note that password managers that are implemented as browser extensions may be vulnerable to [https://www.spookjs.com side channel attacks]. These can be mitigated by using password managers that run as separate applications.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective [https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} ends up on an encrypted partition or/and uses a strong key derivation function (i.e. yescrypt/bcrypt/argon2 or sha512 with PBKDF2, but not md5 or low iterations in PBKDF2) for the stored password hash (see [[SHA password hashes]] for more information).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password.<br />
<br />
Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular argon2, bcrypt, scrypt and PBKDF2, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords with pam_pwquality ===<br />
<br />
''pam_pwquality'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system. It is based on ''pam_cracklib'', so it is backwards compatible with its options.<br />
<br />
[[Install]] the {{Pkg|libpwquality}} package.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy by default.}}<br />
<br />
{{Note|<br />
* You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.<br />
* Current security guidelines around passwords, e.g. from NIST, but also from others, do not recommend enforcing special characters, since they often only lead to predictable alterations.<br />
}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error (retry option)<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 lowercase (lcredit option)<br />
* at least 1 other character (ocredit option)<br />
* cannot contain the words "myservice" and "mydomain"<br />
* enforce the policy for root<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_pwquality''.<br />
<br />
You can refer to the {{man|8|pam_pwquality}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== CPU ==<br />
<br />
=== Microcode ===<br />
<br />
See [[microcode]] for information on how to install important security updates for your CPU's microcode.<br />
<br />
=== Hardware vulnerabilities ===<br />
<br />
Some CPUs contain hardware vulnerabilities. See the [https://docs.kernel.org/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] for a list of these vulnerabilities, as well as mitigation selection guides to help customize the kernel to mitigate these vulnerabilities for specific usage scenarios.<br />
<br />
To check if you are affected by a known vulnerability, run the following:<br />
<br />
$ grep -r . /sys/devices/system/cpu/vulnerabilities/<br />
<br />
In most cases, updating the kernel and microcode will mitigate vulnerabilities.<br />
<br />
==== Simultaneous multithreading (hyper-threading) ====<br />
<br />
[[Wikipedia:Simultaneous multithreading|Simultaneous multithreading]] (SMT), also called hyper-threading on Intel CPUs, is a hardware feature that may be a source of [https://docs.kernel.org/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] and [https://docs.kernel.org/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] vulnerabilities. The Linux kernel and microcode updates contain mitigations for known vulnerabilities, but [https://docs.kernel.org/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests disabling SMT may still be required on certain CPUs if untrusted virtualization guests are present].<br />
<br />
SMT can often be disabled in your system's firmware. Consult your motherboard or system documentation for more information. You can also disable SMT in the kernel by adding the following [[kernel parameters]]:<br />
<br />
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force<br />
<br />
== Memory ==<br />
<br />
=== Hardened malloc ===<br />
<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) is a hardened replacement for [[Wikipedia:GNU C Library|glibc]]'s malloc(). The project was originally developed for integration into Android's [[Wikipedia:Bionic (software)|Bionic]] and [[Wikipedia:musl|musl]] by Daniel Micay, of [[Wikipedia:GrapheneOS|GrapheneOS]], but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in {{ic|/etc/ld.so.preload}}. Since hardened_malloc has a performance cost, you may want to decide which implementation to use on a case-by-case basis based on attack surface and performance needs.<br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox<br />
<br />
Proper usage with [[Firejail]] can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Data-at-rest encryption ===<br />
<br />
[[Data-at-rest encryption]], preferably full-disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full-disk encryption when only certain parts of the system need be secure.<br />
<br />
You may also [[Trusted Platform Module#Data-at-rest encryption with LUKS|encrypt a drive with the key stored in a TPM]], although it has had [https://tpm.fail vulnerabilites in the past] and the key can be extracted by a [https://pulsesecurity.co.nz/articles/TPM-sniffing bus sniffing attack].<br />
<br />
==== File encryption ====<br />
<br />
{{Merge|Data-at-rest encryption|File encryption is still a type of encryption at rest (as opposed to in use or transit).}}<br />
<br />
While data-at-rest encryption is useful at protecting data on physical media, it can not be used to protect data on a remote system that you can not control (such as on cloud storages). In that case, file encryption will be useful.<br />
<br />
These are some methods to encrypt files:<br />
* Some [[Archiving and compression|archiving and compressing]] tools also provide encryption. Some examples are {{Pkg|p7zip}} ({{ic|-p}} flag), {{Pkg|zip}} ({{ic|-e}} flag).<br />
* [[GnuPG]] can be used to [[GnuPG#Encrypt and decrypt|encrypt files]].<br />
* {{Pkg|age}} is a simple and easy to use file encryption tool. It also supports multiple recipients and encryption using SSH keys, which is useful for secure file sharing.<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]*, [[Steam]], PyCharm, etc.<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
=== Backups ===<br />
<br />
{{Merge|System backup|There is a dedicated page for system backups.}}<br />
<br />
Regularly create backups of important data. Regularly test the integrity of the backups. Regularly test that the backups can be restored.<br />
<br />
Make sure that at least one copy of the data is stored offline, i.e. not connected to the system under threat in any way. [[Wikipedia:Ransomware|Ransomware]] and other destructive attacks may also attack any connected backup systems.<br />
<br />
== User setup ==<br />
<br />
=== Do not use the root account for daily use ===<br />
<br />
Following the principle of least privilege, do not use the root user for daily use. Create a non-privileged user account for each person using the system. Use [[sudo]] as necessary for temporary privileged access.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|2=<br />
auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lock out user after three failed login attempts ===<br />
<br />
As of {{Pkg|pambase}} 20200721.1-2, {{ic|pam_faillock.so}} is enabled by default to lock out users for 10 minutes after 3 failed login attempts in a 15 minute period (see {{Bug|67644}}). The lockout only applies to password authentication (e.g. login and ''sudo''), public key authentication over SSH is still accepted. To prevent complete denial-of-service, this lockout is disabled for the root user.<br />
<br />
To unlock a user, do:<br />
<br />
$ faillock --reset --user ''username''<br />
<br />
By default, the lock mechanism is a file per-user located at {{ic|/run/faillock/}}. Deleting or emptying the file unlocks that user—the directory is owned by root, but the file is owned by the user, so the {{ic|faillock}} command only empties the file, therefore does not require root.<br />
<br />
The module {{ic|pam_faillock.so}} can be configured with the file {{ic|1=/etc/security/faillock.conf}}. The lockout parameters:<br />
<br />
* {{ic|unlock_time}} — the lockout time (in seconds, default 10 minutes).<br />
* {{ic|fail_interval}} — the time in which failed logins can cause a lockout (in seconds, default 15 minutes).<br />
* {{ic|deny}} — the number of failed logins before lockout (default 3).<br />
<br />
{{Tip|The primary purpose for the lockout is to slow down brute-force attacks so that they become infeasible. Hence, if lockouts due to mistyping of passwords become too frequent, relaxing the number of attempts may be preferred to reducing the lockout time.}}<br />
<br />
{{Note|{{ic|1=deny = 0}} will disable the lockout mechanism entirely.}}<br />
<br />
By default, all user locks are lost after reboot. If your attacker can reboot the machine, it is more secure if locks persist. To make locks persist, change the {{ic|dir}} parameter in {{ic|1=/etc/security/faillock.conf}} to {{ic|/var/lib/faillock}}.<br />
<br />
No restart is required for changes to take effect. See {{man|5|faillock.conf}} for further configuration options, such as enabling lockout for the root account, disabling for centralized login (e.g. LDAP), etc.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Use Wayland ===<br />
<br />
Prefer using [[Wayland]] over [[Xorg]]. Xorg's design predates modern security practices and is [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] by many. For example, Xorg applications may record keystrokes while inactive.<br />
<br />
If you must run Xorg, it is recommended to [[Xorg#Rootless Xorg|avoid running it as root]]. Within Wayland, the XWayland compatibility layer will automatically use rootless Xorg.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. It is also difficult to audit the root user account. It is therefore important to restrict usage of the root user account as much as possible. There are a number of ways to keep the power of the root user while limiting its ability to cause harm.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There is a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for a number of reasons.<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|2=<br />
alice ALL = NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|2=<br />
Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
See [[Sudo#Editing files]]. Alternatively, you can use an editor like {{ic|rvim}} or {{ic|rnano}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using [[su]]. See [[su#su and wheel]].<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==== Specify acceptable login combinations with access.conf ====<br />
<br />
When someone attempts to log in with [[PAM]], {{ic|/etc/security/access.conf}} is checked for the first combination that matches their login properties. Their attempt then fails or succeeds based on the rule for that combination. <br />
<br />
+:root:LOCAL<br />
-:root:ALL<br />
<br />
Rules can be set for specific groups and users. In this example, the user archie is allowed to login locally, as are all users in the wheel and adm groups. All other logins are rejected:<br />
<br />
+:archie:LOCAL<br />
+:(wheel):LOCAL<br />
+:(adm):LOCAL<br />
-:ALL:ALL<br />
<br />
Read more at {{man|5|access.conf}}<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical (company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[TOMOYO]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
However, it should be noted that several packages will not work when using this kernel. For example:<br />
<br />
* {{AUR|skypeforlinux-preview-bin}}<br />
* {{AUR|skypeforlinux-stable-bin}}<br />
* {{pkg|throttled}}<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened 5.4.21.a-1-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux 5.5.5-arch1-1|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 29 bits (guessed)<br />
Randomization under memory exhaustion @0 : 29 bits (guessed)<br />
}}<br />
<br />
{{hc|linux-lts 4.19.101-1-lts|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 19 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
=== BPF hardening ===<br />
<br />
BPF is a system used to load and execute bytecode within the kernel dynamically during runtime. It is used in a number of Linux kernel subsystems such as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) and security (e.g. seccomp). It is also useful for advanced network security, performance profiling and dynamic tracing.<br />
<br />
BPF was originally an acronym of [[Wikipedia:Berkeley Packet Filter|Berkeley Packet Filter]] since the original classic BPF was used for packet capture tools for BSD. This eventually evolved into Extended BPF (eBPF), which was shortly afterwards renamed to just BPF (not an acronym). BPF should not be confused with packet filtering tools like iptables or netfilter, although BPF can be used to implement packet filtering tools.<br />
<br />
BPF code may be either interpreted or compiled using a [[Wikipedia:Just-in-time compilation|Just-In-Time (JIT) compiler]]. The Arch kernel is built with {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} which disables the BPF interpreter and forces all BPF to use JIT compilation. This makes it harder for an attacker to use BPF to escalate attacks that exploit SPECTRE-style vulnerabilities. See [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb the kernel patch which introduced CONFIG_BPF_JIT_ALWAYS_ON] for more details.<br />
<br />
The kernel includes a hardening feature for JIT-compiled BPF which can mitigate some types of JIT spraying attacks at the cost of performance and the ability to trace and debug many BPF programs. It may be enabled by setting {{ic|net.core.bpf_jit_harden}} to {{ic|1}} (to enable hardening of unprivileged code) or {{ic|2}} (to enable hardening of all code).<br />
<br />
See the {{ic|net.core.bpf_*}} settings in the [https://docs.kernel.org/admin-guide/sysctl/net.html kernel documentation] for more details.<br />
<br />
{{Tip|<br />
* {{Pkg|linux-hardened}} sets {{ic|1=net.core.bpf_jit_harden=2}} by default rather than {{ic|0}}.<br />
* By default, BPF programs can be run even by unprivileged users. To change that behaviour set {{ic|1=kernel.unprivileged_bpf_disabled=1}}[https://access.redhat.com/security/cve/cve-2021-33624].<br />
}}<br />
<br />
=== ptrace scope ===<br />
<br />
The {{man|2|ptrace}} syscall provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. {{ic|ptrace}} is commonly used by debugging tools including ''gdb'', ''strace'', ''perf'', ''reptyr'' and other debuggers. However, it also provides a means by which a malicious process can read data from and take control of other processes.<br />
<br />
Arch enables the [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] by default, which provides a {{ic|kernel.yama.ptrace_scope}} [[kernel parameter]]. This parameter is set to {{ic|1}} (restricted) by default which prevents tracers from performing a {{ic|ptrace}} call on traces outside of a restricted scope unless the tracer is privileged or has the {{ic|CAP_SYS_PTRACE}} [[Capabilities|capability]]. This is a significant improvement in security compared to the classic permissions. Without this module, there is no separation between processes running as the same user (in the absence of additional security layers such as {{man|7|pid_namespaces}}).<br />
<br />
{{Note|By default, you can still use tools which require {{ic|ptrace}} by running them as privileged processes, e.g. using [[sudo]].}}<br />
<br />
If you do not need to use debugging tools, consider setting {{ic|kernel.yama.ptrace_scope}} to {{ic|2}} (admin-only) or {{ic|3}} (no {{ic|ptrace}} possible) to harden the system.<br />
<br />
=== hidepid ===<br />
<br />
{{Expansion|1=[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fb5ce62c5920b6e0a8a061f2fe80e0403281e10 Linux 5.8 implemented private instances] and new values for {{ic|1=hidepid=}}.}}<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[Polkit]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented in https://docs.kernel.org/filesystems/proc.html. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users and groups#System groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users and groups#Group management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|virtualbox-host-modules-arch}} cannot be loaded. Kernel module loading can be restricted by setting the [[kernel parameter]] {{ic|1=module.sig_enforce=1}}. More information can be found at the [https://docs.kernel.org/admin-guide/module-signing.html kernel documentation].<br />
<br />
=== Disable kexec ===<br />
<br />
Kexec allows replacing the current running kernel.<br />
<br />
{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=<br />
kernel.kexec_load_disabled = 1<br />
}}<br />
<br />
{{Tip|kexec is disabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
=== Kernel lockdown mode ===<br />
<br />
Since Linux 5.4 the kernel [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d has gained] an optional [https://mjg59.dreamwidth.org/55105.html lockdown feature], intended to strengthen the boundary between UID 0 (root) and the kernel. When enabled some applications may cease to work who rely on low-level access to either hardware or the kernel.<br />
<br />
To use lockdown, its LSM must be initialized and a lockdown mode must be set.<br />
<br />
All [[Kernel#Officially supported kernels|officially supported kernels]] initialize the LSM, but none of them enforce any lockdown mode. <br />
<br />
{{Tip|Enabled LSMs can be verified by running {{ic|cat /sys/kernel/security/lsm}}.}}<br />
<br />
Lockdown has two modes of operation:<br />
<br />
* {{ic|integrity}}: kernel features that allow userland to modify the running kernel are disabled (kexec, bpf).<br />
* {{ic|confidentiality}}: kernel features that allow userland to extract confidential information from the kernel are also disabled.<br />
<br />
To enable kernel lockdown at runtime, run:<br />
<br />
# echo ''mode'' > /sys/kernel/security/lockdown<br />
<br />
To enable kernel lockdown on boot, use the [[kernel parameter]] {{ic|1=lockdown=''mode''}}.<br />
<br />
{{Note|<br />
* Kernel lockdown cannot be disabled at runtime.<br />
* Kernel lockdown disables [[hibernation]].<br />
}}<br />
<br />
See also {{man|7|kernel_lockdown}}.<br />
<br />
=== Linux Kernel Runtime Guard (LKRG) ===<br />
<br />
[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) is a kernel module which performs integrity checking of the kernel and detection of exploit attempts.<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (4.14.5 or later), {{Pkg|linux-lts}} (4.14.15 or later), {{Pkg|linux-zen}} (4.14.4-2 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
{{Warning|Unprivileged user namespace usage ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) is enabled by default in {{Pkg|linux}} (5.1.8 or later), {{Pkg|linux-lts}} (4.19.55-2 or later) and {{Pkg|linux-zen}} (5.1.14.zen1-2 or later) unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|0}}. Since this greatly increases the attack surface for local privilege escalation, it is advised to disable this manually, or use the {{Pkg|linux-hardened}} kernel. For more information see {{Bug|36969}}.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and complex sandboxes.<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC is run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general information.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
* {{AUR|Opensnitch}} is a configurable inbound and outbound firewall with support for configurable rules by application, port, host, etc.<br />
<br />
==== Open ports ====<br />
<br />
{{Style|"Open ports" is not a good title since it disregards interfaces and addresses that the application may be bound to. From the firewalls' point of view, ports may be "open" even if no application listens on them at the moment.}}<br />
<br />
Some services listen for inbound traffic on open network ports. It is important to only bind these services to the addresses and interfaces that are strictly necessary. It may be possible for a remote attacker to [https://samy.pl/slipstream/ exploit flawed network protocols to access exposed services]. This can even happen with [https://nvd.nist.gov/vuln/detail/CVE-2019-13450 processes bound to localhost].<br />
<br />
In general, if a service only needs to be accessible to the local system, bind to a Unix domain socket ({{man|7|unix}}) or a loopback address such as {{ic|localhost}} instead of a non-loopback address like {{ic|0.0.0.0/0}}.<br />
<br />
If a service needs to be accessible to other systems via the network, control the access with strict [[firewall]] rules and configure authentication, authorization and encryption whenever possible.<br />
<br />
You can list all current open ports with {{ic|ss -l}}. To show all '''l'''istening '''p'''rocesses and their '''n'''umeric '''t'''cp and '''u'''dp port numbers:<br />
<br />
# ss -lpntu<br />
<br />
See {{man|8|ss}} for more options.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[firewall]] rules but open up the potential for a denial of service, since an attacker can [[wikipedia:Spoofing_attack#Spoofing_and_TCP/IP|spoof]] packets as if they came from the administrator after identifying their address. Spoofing IP has lines of defense, such as by [[sysctl#Reverse path filtering|reverse path filtering]] and [[sysctl#Disable ICMP redirects|disabling ICMP redirects]].<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
Mozilla publishes an [https://infosec.mozilla.org/guidelines/openssh.html OpenSSH configuration guide] which configures more verbose audit logging and restricts ciphers.<br />
<br />
=== DNS ===<br />
<br />
The default domain name resolution (DNS) configuration is highly compatible but has security weaknesses. See [[Domain name resolution#Privacy and security|DNS privacy and security]] for more information.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing TLS certificates ===<br />
<br />
See [[TLS#Trust management]].<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access by default.[https://web.archive.org/web/20210312083421/http://breaknenter.org/2014/09/inception-metasploit-integration/] For Thunderbolt, you can restrict the direct memory access completely or to known devices, see [[Thunderbolt#User device authorization]]. For Firewire and PCI Express, here is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Data-at-rest encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Boot loaders ===<br />
<br />
It is highly important to protect your [[boot loader]]. An unprotected boot loader can bypass any login restrictions, e.g. by setting the {{ic|1=init=/bin/sh}} [[kernel parameter]] to boot directly to a shell.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Secure Boot ===<br />
<br />
[[Secure Boot]] is a feature of [[UEFI]] that allows authentication of the files your computer boots. This helps preventing some [[Wikipedia:Evil maid attack|evil maid attacks]] such as replacing files inside the boot partition. Normally computers come with keys that are enrolled by vendors (OEM). However these can be removed and allow the computer to enter ''Setup Mode'' which allows the user to enroll and manage their own keys.<br />
<br />
The secure boot page guides you through how to set secure boot up by [[Unified Extensible Firmware Interface/Secure Boot#Using your own keys|using your own keys]].<br />
<br />
=== Trusted Platform Module (TPM) ===<br />
<br />
[[Trusted Platform Module|TPMs]] are hardware microprocessors which have cryptographic keys embedded. This forms the fundamental root of trust of most modern computers and allows end-to-end verification of the boot chain. They can be used as internal smartcards, attest the firmware running on the computer and allow users to insert secrets into a tamper-proof and brute-force resistant store.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Data-at-rest encryption|full-disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted system using a detached LUKS header|detached encryption headers]] placed on the boot partition.<br />
<br />
This method can also be merged with [[Dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB|encrypting /boot]].<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://opensource.srlabs.de/projects/badusb BadUSB], [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
=== Volatile data collection ===<br />
<br />
A computer that is powered on may be vulnerable to [https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection]. It is a best practice to turn a computer completely off at times it is not necessary for it to be on, or if the computer's physical security is temporarily compromised (e.g. when passing through a security checkpoint).<br />
<br />
== Packages ==<br />
<br />
=== Authentication ===<br />
<br />
[https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www2.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
=== Upgrades ===<br />
<br />
It is important to regularly [[System maintenance#Upgrading the system|upgrade the system]].<br />
<br />
=== Follow vulnerability alerts ===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. The tool {{Pkg|arch-audit}} can be used to check for vulnerabilities affecting the running system. A graphical system tray, {{Pkg|arch-audit-gtk}}, can also be used. See also [[Arch Security Team]].<br />
<br />
You should also consider subscribing to the release notifications for software you use, especially if you install software through means other than the main repositories or AUR. Some software have mailing lists you can subscribe to for security notifications. Source code hosting sites often offer RSS feeds for new releases.<br />
<br />
=== Rebuilding packages ===<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
{{Merge|Arch package guidelines/Security|Security related build flags have their own article.}}<br />
<br />
{{Accuracy|Copy-pasted from a 3 years old blog post. The compiler flags are specific to [[GCC]], some are hardly security related (e.g. {{ic|-O2}}, {{ic|-g}}, {{ic|-Wall}}).}}<br />
<br />
{| class="wikitable"<br />
! Flag !! Purpose<br />
|-<br />
| -D_FORTIFY_SOURCE=2 || Run-time buffer overflow detection <br />
|-<br />
| -D_GLIBCXX_ASSERTIONS || Run-time bounds checking for C++ strings and containers <br />
|-<br />
| -fasynchronous-unwind-tables || Increased reliability of backtraces <br />
|-<br />
| -fexceptions || Enable table-based thread cancellation <br />
|-<br />
| -fpie -Wl,-pie || Full ASLR for executables <br />
|-<br />
| -fpic -shared || No text relocations for shared libraries <br />
|-<br />
| -fplugin=annobin || Generate data for hardening quality control <br />
|-<br />
| -fstack-clash-protection || Increased reliability of stack overflow detection <br />
|-<br />
| -fstack-protector or -fstack-protector-all || Stack smashing protector <br />
|-<br />
| -fstack-protector-strong || Likewise <br />
|-<br />
| -g || Generate debugging information <br />
|-<br />
| -grecord-gcc-switches || Store compiler flags in debugging information <br />
|-<br />
| -mcet -fcf-protection || Control flow integrity protection <br />
|-<br />
| -O2 || Recommended optimizations <br />
|-<br />
| -pipe || Avoid temporary files, speeding up builds <br />
|-<br />
| -Wall || Recommended compiler warnings <br />
|-<br />
| -Werror=format-security || Reject potentially unsafe format string arguments <br />
|-<br />
| -Werror=implicit-function-declaration || Reject missing function prototypes <br />
|-<br />
| -Wl,-z,defs || Detect and reject underlinking <br />
|-<br />
| -Wl,-z,now || Disable lazy binding <br />
|-<br />
| -Wl,-z,relro || Read-only segments after relocation <br />
|}<br />
<br />
* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info source]<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://developer.ibm.com/technologies/linux/articles/l-harden-desktop/ Hardening the Linux desktop]<br />
* [https://web.archive.org/web/20190701140035/https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacyguides.org/ privacyguides.org Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html Securing Debian Manual]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Arch_Linux_on_a_VPS&diff=673279Arch Linux on a VPS2021-05-24T22:05:26Z<p>Thestinger: /* Providers that offer Arch Linux */ fix typo</p>
<hr />
<div>[[Category:Installation process]]<br />
[[Category:Virtualization]]<br />
[[ja:Arch Linux VPS]]<br />
[[zh-hans:Arch Linux on a VPS]]<br />
{{Related articles start}}<br />
{{Related|Server}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Virtual private server]]:<br />
<br />
:Virtual private server (VPS) is a term used by Internet hosting services to refer to a virtual machine. The term is used for emphasizing that the virtual machine, although running in software on the same physical computer as other customers' virtual machines, is in many respects functionally equivalent to a separate physical computer, is dedicated to the individual customer's needs, has the privacy of a separate physical computer, and can be configured to run server software.<br />
<br />
This article discusses the use of Arch Linux on Virtual Private Servers, and includes some fixes and installation instructions specific to VPSes.<br />
<br />
{{Warning|<br />
* Since many container-based virtualization environments rely on older kernels, it may be impossible to keep an Arch Linux install up-to-date in such an environment. Linux 2.6.32, used by OpenVZ 6, is not supported by systemd since version 205 (and will not work with systemd-212 or higher). OpenVZ does sometimes backport newer kernel features into its kernel, but as of 2018-06-27, a fresh installation of Arch does not work on OpenVZ 6 kernel version 2.6.32-042stab131.1 . Arch can be installed on OpenVZ 7, with [[#Preparing the Arch build for use on an OpenVZ 7 container|a minor workaround]], as of OpenVZ 7 kernel version 3.10.0-693-21.1.vz7.48.2 .}}<br />
<br />
== Official Arch Linux cloud image ==<br />
<br />
Arch Linux provides a official cloud image as part of the [https://gitlab.archlinux.org/archlinux/arch-boxes arch-boxes project]. The image comes with [[Cloud-init]] preinstalled and should work with most cloud providers.<br />
<br />
The image can be downloaded from the mirrors under the {{ic|images}} directory. Instructions for tested providers is listed below:<br />
<br />
{| class="wikitable"<br />
! Provider !! Locations !! Note<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || Global ||<br />
# Find the cloud image on a mirror, ex: {{ic|https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Add the image as a custom image by [https://www.digitalocean.com/docs/images/custom-images/quickstart/#upload-images importing it]<br />
# [https://www.digitalocean.com/docs/images/custom-images/quickstart/#create-droplets-from-custom-images Create a new VM from the custom image]<br />
# SSH to the VM: {{ic|ssh root@<ip>}}<br />
|-<br />
| [https://www.hetzner.com/cloud Hetzner Cloud] || Nuremberg, Falkenstein (Germany), Helsinki (Finland) ||<br />
# Create a new VM with this user data:{{bc|#cloud-config<br><nowiki>vendor_data: {'enabled': false}</nowiki>}}<sup>The {{ic|vendor_data}} from Hetzner overrides the {{ic|distro}} and sets the default user to {{ic|root}} without setting {{ic|disable_root: false}}, meaning you can not login</sup><br />
# Boot the VM in rescue mode<br />
# SSH to the VM and download the cloud image from a mirror, ex: {{ic|curl -O https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Write the image to the disk: {{ic|qemu-img convert -f qcow2 -O raw Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 /dev/sda}}<br />
# Reboot the VM<br />
# SSH to the VM: {{ic|ssh arch@<ip>}}<br />
|-<br />
| [https://www.proxmox.com/ Proxmox] || N/A ||<br />
# Create a new VM<br />
# Select "Do not use any media" in OS section.<br />
# Remove created hard disk from your VM after VM creation completes.<br />
# Add the downloaded image to your VM using {{ic|qm importdisk}}, ex:<br> {{ic|qm importdisk 100 Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 local}}<br />
# Add a cloudinit drive and make your configurations in Cloud-Init section.<br />
# Start the VM!<br />
|-<br />
|}<br />
<br />
== Providers that offer Arch Linux ==<br />
<br />
{{Style|Inconsistency, some language issues}}<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|This list is for providers with a convenient Arch Linux template. Using Arch on other providers is possible but requires more work. Example methods include: <br />
* Loading custom disc images (requires hardware virtualization such as in Xen or KVM), <br />
** Ex the official [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Arch cloud image]<br />
* [[Installation guide|Installing under chroot]], for example with the help of the [https://gitlab.com/drizzt/vps2arch/ vps2arch] script (it will download the latest iso; be particularly aware of the systemd 220/221 [https://github.com/systemd/systemd/issues/421 bug]), or <br />
* Following [[#Installing the latest Arch Linux on any OpenVZ container provider]] instructions, using rsync to synchronize Arch over the top of another distribution.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Archiso release !! Virtualization !! Locations !! Notes<br />
|-<br />
| [https://www.1984hosting.com/ 1984hosting.com] || 2016.x || Xen || Iceland (IS) || [https://www.1984hosting.com/product/vps/ Hardware] will provide any image you request, has Arch in default image list.<br />
|-<br />
| [https://4smart.cz/ 4smart.cz] || 2013.08 || OpenVZ || Prague, CZ || (Czech language site only) when updating system make sure you use [tredaelli-systemd] in pacman.conf (see [[Unofficial user repositories]]<br />
|-<br />
| [https://www.affinity.net.nz/ affinity.net.nz] || 2013.08.01 || KVM || Auckland, New Zealand (NZ) || IRC channel is #affinity on ircs.kiwicon.org<br />
|-<br />
| [https://www.atlantic.net/ Atlantic.Net] || 2016.03.01 || KVM || NYC/SF/Toronto/Dallas/Orlando, US & Canada || 100% SSD 1-click Arch Linux, ready in 30 seconds. It is also easy to update Arch to the current version because the pre-provisioned Arch image is relatively current.<br />
|-<br />
| [https://buyvm.net/ BuyVM] || 2017.08.01 || KVM || Buffalo, (US-NY); Las Vegas, (US-NV); Luxembourg, Germany (DE) || Cannot select Arch at purchase. Once purchased, use Stallion control panel to install Arch manually from ISO. <br />
|-<br />
| [https://cloudvip.be CloudVIP] || Latest || KVM || Brussels, Belgium || French site and support.<br />
|-<br />
| [https://coinshost.com/en/vps Coinshost] || 2015.04 || Xen || Zurich, Switzerland || Bitcoin and other cryptocurrencies accepted.<br />
|-<br />
| [https://cherry.host Cherry Host] || Latest || KVM || Santee, US-CA || Must submit a support ticket to get Arch installed.<br />
|-<br />
| [https://contabo.com Contabo] || Latest || KVM || Germany || Only place to get 500 GB for 7€ - Decent speed. Other cheaps plans add snapshots, which is useful if you VPS runs a rolling release distro.<br />
|-<br />
| [https://www.directvps.nl/ DirectVPS] || 2014.01.xx || OpenVZ || Amsterdam, NL; Rotterdam, NL || (Dutch language site only)<br />
|-<br />
| [https://www.edis.at/en/ Edis] || [https://www.edis.at/en/server/available-distributions-and-os 2019.02.01] || vServer, KVM, OpenVZ || [https://www.edis.at/en/hosting/international-server-locations Multiple international locations]. || Also offer dedicated server options as well as an "off-shore" location at the Isle of Man (IM). Requires mounting an Arch ISO for a full manual install.<br />
|-<br />
| [https://hetzner.com/cloud Hetzner] || 2020.06.01 || KVM || Nuremberg, DE; Falkenstein, DE; Helsinki, FI || You cannot choose Arch Linux directly on the order form. Order Ubuntu or something first, then go to ISO Images, mount Arch Linux, reboot server, and log in to web console to complete installation.<br />
|-<br />
| [https://www.gigatux.com/virtual.php GigaTux] || [https://www.gigatux.com/distro/ 2013.06.01] || Xen || Chicago, US-IL; Frankfurt, DE; London, GB; San Jose, US-CA || Currently, when changing to the US$ currency, the page breaks and it is not possible to provision a server.<br />
|-<br />
| [https://leapswitch.com Leapswitch Networks] || 2013.10.xx || OpenVZ/KVM || USA, India, Portugal, Spain, Ukraine, Germany || Arch Linux currently available in Control Panel for reinstall, not on order form. <br />
|-<br />
| [https://linevast.de Linevast.de] || Latest || OpenVZ, KVM || Germany || Arch Linux is possible on openvz and on KVM with the one click os installer. <br />
|-<br />
| [https://www.linode.com Linode] || [https://www.linode.com/distributions Latest] || KVM || [https://www.linode.com/speedtest/ Multiple US, London, Frankfurt, Tokyo, Singapore] || Linode instances are configured to run Arch's kernel by default. Linode provides custom kernels which can be selected in the manager settings. There are also community-supported kernels in the AUR, such as {{AUR|linux-linode}}.<br />
|-<br />
| [http://lylix.net/ LYLIX] || [http://lylix.net/archlinux 2014.01.xx]{{Dead link|2021|05|09|status=404}} || OpenVZ || Multiple US; Europe || 32-bit and 64-bit available <br />
|-<br />
| [https://www.netcup.eu/ Netcup] || 2020.09.01 || KVM || Germany (DE)|| German language: [https://www.netcup.de/ Netcup]<br />
|-<br />
| [https://www.medhahosting.com MedHaHosting ] || Latest || KVM || Buffalo, NY, USA; Atlanta, GA, USA; Chicago, IL, USA; Los Angeles, CA, USA || Arch Linux available on request. Many Linux and Windows hosting options. <br />
|-<br />
| [https://monovm.com MonoVM ] || Latest || VMware || USA - Canada - Netherlands - Germany - UK - France - Denmark || VMware Based VPS Server Provider. <br />
|-<br />
| [https://www.onepoundwebhosting.co.uk/ OnePoundWebHosting] || 2014.01 || Xen PV, Xen HVM || United Kingdom (UK) || They are a registrar too. Unable to verify server locations.<br />
|-<br />
| [https://www.ovh.com/us/vps/ OVH] || Latest || KVM || Beauharnois, Canada (CA); Frankfurt, Germany (DE); Gravelines, Stratsbourg, France (FR); Warsaw, Poland (PL); London, United Kingdom (UK) || Disable and remove {{pkg|dhcpcd}} from the standard image to avoid long delays from conflicts with systemd-networkd. The default /etc/locale.gen also needs to be fixed due to an invalid value from cloud-init followed by running {{ic|locale-gen}}. Can also disable and remove [[haveged]] now that it's obsolete.<br />
|-<br />
| [https://pacmanvps.com/ PacmanVPS] || 2014.01 || KVM || Canada (CA), Poland (PL) || Arch image is very old and PacmanVPS repos are broken. Not possible to update Arch. Site appears unmaintained.<br />
|-<br />
| [https://www.proplay.de/ Proplay] || Latest || OpenVZ, KVM || Germany (DE) || (German language site only)<br />
|-<br />
| [https://www.rackspace.com/cloud/servers Rackspace Cloud] || 2013.6 || Xen || [https://www.rackspace.com/whyrackspace/network/datacenters/ Multiple international locations]{{Dead link|2020|12|19|status=404}} || Billed per hour. Use their "next gen" VPSes (using the mycloud.rackspace.com panel); the Arch image on the first gen Rackspace VPSes is out of date.<br />
|-<br />
| [https://www.ramhost.us/ RamHost.us] || [https://www.ramhost.us/?page=news 2013.05.01] || OpenVZ, KVM || Los Angeles, US-CA; Great Britain (GB); Atlanta, US-GA; Germany (DE) || You can request a newer ISO on RamHost's IRC network.<br />
|-<br />
| [https://www.ramnode.com/ RamNode] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=48 2016.01.01] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=39 SSD and SSD Cached:] [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=52 KVM] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=50 Alblasserdam, NL; Atlanta, GA-US; Los Angeles, CA-US; New York, NY-US; Seattle, WA-US] || You can request Host/CPU passthrough with KVM service.[https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=66] Frequent use of discount promotions.[https://twitter.com/search?q=ramnode%20code&src=typd], Must install Arch manually from an ISO using VNC viewer.<br />
|-<br />
| [https://www.rosehosting.com/ RoseHosting] || Latest || OpenVZ, KVM || St. Louis, Missouri, USA || SSD powered hosting plans with free fully-managed 24/7 support. No unmanaged VPS offerings.<br />
|-<br />
| [https://www.seedvps.com/ SeedVPS] || Latest || OpenVZ, KVM || Amsterdam, Netherlands || Linux VPS and Windows VPS Hosting in The Netherlands (NL). Newer ISO can be requested by opening a support ticket.<br />
|-<br />
| [https://www.servercheap.net Server Cheap] || Latest || OpenVZ, KVM || Chicago, Illinois, USA || Arch Linux available on request. Windows, BSD, and many Linux distribution hosting options. <br />
|-<br />
| [https://skyhost.ru/ SkyHost] || Latest || LXC || Moscow, Yaroslavl, Russia || <br />
|-<br />
| [https://www.tilaa.com/ Tilaa] || 2016.03.01 || [https://www.tilaa.com/pages/vps/technology KVM]{{Dead link|2020|03|28|status=404}} || Amsterdam, NL ||<br />
|-<br />
| [https://www.transip.eu/ TransIP] || latest || [https://www.transip.eu/vps/vps-technology/ KVM] || Amsterdam, NL || For latest image, submit ticket. Also registrar.<br />
|-<br />
| [https://upcube.io upCUBE]{{Dead link|2021|05|09|status=domain name not resolved}} || Latest || Docker || Germany || Different prepared arch linux templates available<br />
|-<br />
| [https://virpus.com/ Virpus] || [https://virpus.com/linux-vps.php 2014.11.07] || Xen || Kansas City, US-KS; Los Angeles, US-CA || Arch is '''not''' offered as a choice when creating a server (even though the Arch logo is prominently featured on the site). As of 2018, the most recent version of Ubuntu offered is 14.04, and the limited-time promo code for new sign ups is over two years old. None of this generates much trust.<br />
|-<br />
| [https://www.virtualmaster.com/ Virtual Master] || 2012-08 || ?? || Prague, CZ ||<br />
|-<br />
| [https://vps6.net/ VPS6.NET] || 2013.01.xx || OpenVZ, Xen, HVM-ISO || [http://vps6.net/network/ Multiple US]; Frankfurt, DE; Bucharest, RO; Istanbul, TR || Registrar.<br />
|-<br />
| [https://www.vpsbg.eu/ VPSBG.eu] || 2013.10 || OpenVZ || [https://vpsbg.eu/en/index.php?page=vps-datacenter Sofia, Bulgaria] || Offshore VPS in Bulgaria - anonymous registrations and Bitcoin are accepted.<br />
|-<br />
| [https://www.vpscheap.net VPSCHEAP] || 2016.10 || NVM KVM || Dallas, TX, USA || Has one plan that allows you to select Arch Linux, but does not appear in any other plan, but available on request. The system is severely outdated. To fix it install archlinux-keyring, then run pacman -Syu.<br />
|-<br />
| [https://www.vpsserver.com/ VPSSERVER] || 2015.07 || KVM || Chicago, US-IL; Dallas, US-TX; Miami, US-FL; New York, US-NY; Silicon Valley, US-CA; Amsterdam, NL; Frankfurt, DE; London, UK || Currently the latest Arch Linux OS version we are providing is 2015.07 x64 and you cannot update the OS version to the new version.<br />
|-<br />
| [https://www.vultr.com/ Vultr] || Latest || KVM || [https://www.vultr.com/locations/ Multiple International locations] || When deploying a new server just select the Arch install ISO from Vultr ISO Library. Then just manually run through the standard [[Installation guide|Arch installation guide]].<br />
|-<br />
| [https://www.world4you.com/ World4You] || 2015.10.28 || OpenVZ || Austria (AT) || Internet hosting provider; quick setup; 24/7 support; shared web hosting; also CentOS, Debian, Ubuntu, Fedora and Arch OpenVZ servers; supports newest systemd (227 atm)<br />
|-<br />
| [http://www.xenvz.co.uk/ XenVZ] || 2009.12.07 || OpenVZ, Xen || United Kingdom (UK), United States (US) || [http://www.xenvz.co.uk/faq.php#use2 Hardware]<br />
|-<br />
| [https://zappiehost.com/ ZappieHost] || Latest || LXC || Auckland, New Zealand (NZ) || Hosted on redundant SSDs. Kernel 4.X using LXC<br />
|-<br />
| [https://www.misaka.io/ Misaka.io / zeptoVM] || Latest || KVM || [https://www.misaka.io/services/mc2 Multiple International locations] || Images are built every 24 hrs<br />
|-<br />
|}<br />
<br />
== Providers with Community provided Arch Linux support ==<br />
<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|Arch Linux is not officially supported by these providers. The images and scripts listed here are created by the community.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Installation Type !! Locations !! Notes<br />
|- <br />
| [https://aws.amazon.com/ Amazon Web Services] || [[Arch Linux AMIs for Amazon Web Services|Custom Images]] || Global ||<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Official Arch cloud image], [https://github.com/gh2o/digitalocean-debian-to-arch Conversion Script] or [https://github.com/robsonde/digitalocean_builder Custom Image] || Global || IPv6 does not work with custom images, but works with conversion script<br />
|-<br />
| [https://cloud.google.com/ Google Cloud Platform] || [https://github.com/GoogleCloudPlatform/compute-archlinux-image-builder Custom Image] || Global || <br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
=== KVM ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[QEMU#Preparing an (Arch) Linux guest]].<br />
<br />
=== OpenVZ ===<br />
<br />
==== Installing the latest Arch Linux on any OpenVZ container provider ====<br />
<br />
{{Warning|Please refer to the warning about the older kernel version and systemd at the top of the page, and note the [[#Preparing the Arch build for use on an OpenVZ 7 container|workaround for OpenVZ 7 below]].}}<br />
<br />
It is possible to directly copy an installation of Arch Linux over the top of a working OpenVZ VPS. This tutorial explains how to create a basic installation of Arch Linux with {{ic|pacstrap}} (as used in a standard install) and then replace the contents of a target VPS with it using [[rsync]].<br />
<br />
This process (with minor modification) also works to migrate existing Arch installations between various environments and has been confirmed to work in migrating from OpenVZ to Xen and from Xen to OpenVZ. For an install to Xen, other hardware-virtualized platforms, or even to physical hardware, extra steps (basically running {{ic|mkinitcpio}} and installing a [[boot loader]]) are needed.<br />
<br />
===== Prerequisites =====<br />
<br />
* A working Arch Linux installation<br />
** To keep things simple, it should match the architecture you want to install on your VPS (x86_64 or i686).<br />
** To build from other distributions, [[Archbootstrap|arch-bootstrap.sh]] can be used in place of {{ic|pacstrap}}.<br />
* The {{Pkg|arch-install-scripts}}, {{Pkg|rsync}}, and {{Pkg|openssh}} packages from the [[official repositories]]<br />
** SSH is not strictly required, but rsync over SSH is the method used here.<br />
* A VPS running any distribution, with {{ic|rsync}} and a working SSH server<br />
** Its architecture (x86_64 or i686) does not matter as long as the OpenVZ installation can support your target architecture.<br />
* OpenVZ's serial console feature (usually accessible via your provider's control panel)<br />
** Without this, any network configuration for the target VPS will have to be done immediately after the "Build" step below.<br />
<br />
===== Building a clean Arch Linux installation =====<br />
<br />
As root, build the installation (optionally replacing {{ic|build}} with your preferred target directory):<br />
<br />
# mkdir build<br />
# pacstrap -cd build<br />
<br />
Other tweaks for the {{ic|pacstrap}} command:<br />
<br />
*{{ic|-C custom-pacman-config.conf}} - Use a custom pacman configuration file. By default, {{ic|pacstrap}} builds according to your local pacman.conf. This determines the architecture (i686 or x86_64) of the build, the mirror list, etc.<br />
*{{ic|-G}} - Prevent {{ic|pacstrap}} from copying your system's pacman keyring to the new build. If you use this option, you will need to run {{ic|pacman-key --init}} and {{ic|pacman-key --populate archlinux}} in the [[#Configuration|Configuration]] step to set up the keyring.<br />
*{{ic|-M}} - Prevent {{ic|pacstrap}} from copying your system's pacman mirror list to the new build.<br />
*You can pass a list of packages to {{ic|pacstrap}} to add them to your install, instead of the default {{ic|base}} group. For example: {{ic|pacstrap -cd build base openssh dnsutils gnu-netcat traceroute vim}}<br />
<br />
====== Preparing the Arch build for use on an OpenVZ 7 container ======<br />
<br />
OpenVZ 7 will fail to start a container if some expected network configuration files do not exist. The easiest way to get around this is as follows:<br />
<br />
# Create the OpenVZ 7 container as Debian 8 (Debian 9 would probably work as well).<br />
# Create the required blank network configuration files inside the Arch build, as follows:<br />
# mkdir build/etc/network<br />
# touch build/etc/network/interfaces<br />
# mkdir -p build/etc/resolvconf/resolv.conf.d<br />
# touch build/etc/resolvconf/resolv.conf.d/base<br />
<br />
===== Replacing everything on the VPS with the Arch build =====<br />
<br />
Replace all files, directories, etc. on your target VPS with the contents of your {{ic|build}} directory (replacing "YOUR.VPS.IP.ADDRESS" below):<br />
<br />
{{Warning|Be careful with the following command. By design, {{ic|rsync}} is very destructive, especially with any of the {{ic|--delete}} options.}}<br />
<br />
# rsync -axH --numeric-ids --delete-delay -e ssh --stats -P build/ YOUR.VPS.IP.ADDRESS:/<br />
<br />
Explanation of options:<br />
<br />
* {{ic|-a}} - Required. Preserves timestamps, permissions, etc.<br />
* {{ic|--delete}} - Required. Deletes anything in the target that does not exist in the source<br />
* {{ic|-x}} - Important. Prevents the crossing of filesystem boundaries (other partitions, /dev, etc.) during the copy<br />
* {{ic|-H}} - Important. Preserves hardlinks<br />
* {{ic|--numeric-ids}} - Important. Does not assign user/group ownership of files based on matching user and group names and instead uses the numeric IDs directly, ensuring proper file ownership on the target system<br />
* {{ic|--delete-delay}} - Recommended. Enables alternate deletion mode which waits to delete anything until the synchronization is otherwise complete, which may reduce the risk of a slow transfer causing the target VPS to lock-up<br />
* {{ic|-e ssh}} - Recommended. Uses {{ic|rsync}} over SSH (recommended for simplicity compared to setting up an {{ic|rsync}} server)<br />
* {{ic|-P}} - Recommended. Shows partial progress information during transfer<br />
* {{ic|--stats}} - Recommended. Shows transfer statistics at the end<br />
<br />
===== Configuration =====<br />
<br />
# Reboot the VPS externally (using your provider's control panel, for example).<br />
# Using OpenVZ's serial console feature, configure the [[network]] and [[Installation_guide#Configure_the_system|basic system settings]] (ignoring fstab generation and arch-chroot steps).<br />
#* If you do not have access to the serial console feature, you will need to preconfigure your network settings before synchronizing Arch to the VPS.<br />
#* On some VPS configuration you will not have a gateway to connect to, here is an example [[netctl]] configuration for this setup. It configures static IP addresses and default routes on venet0 and uses Google Public DNS.<br />
{{hc|/etc/netctl/venet|2=<br />
Description='VPS venet connection'<br />
Interface=venet0<br />
Connection=ethernet<br />
<br />
IP=static<br />
Address=('192.0.2.42/32')<br />
Routes=('default')<br />
<br />
IP6=static<br />
Address6=('2001:db8::1234:5678/128')<br />
Routes6=('default')<br />
<br />
DNS=('2001:4860:4860::8888' '2001:4860:4860::8844' '8.8.8.8' '8.8.4.4')<br />
}}<br />
<br />
=== Xen ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[Xen]].</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Arch_Linux_on_a_VPS&diff=673240Arch Linux on a VPS2021-05-24T21:50:16Z<p>Thestinger: another OVH Arch image annoyance to work around</p>
<hr />
<div>[[Category:Installation process]]<br />
[[Category:Virtualization]]<br />
[[ja:Arch Linux VPS]]<br />
[[zh-hans:Arch Linux on a VPS]]<br />
{{Related articles start}}<br />
{{Related|Server}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Virtual private server]]:<br />
<br />
:Virtual private server (VPS) is a term used by Internet hosting services to refer to a virtual machine. The term is used for emphasizing that the virtual machine, although running in software on the same physical computer as other customers' virtual machines, is in many respects functionally equivalent to a separate physical computer, is dedicated to the individual customer's needs, has the privacy of a separate physical computer, and can be configured to run server software.<br />
<br />
This article discusses the use of Arch Linux on Virtual Private Servers, and includes some fixes and installation instructions specific to VPSes.<br />
<br />
{{Warning|<br />
* Since many container-based virtualization environments rely on older kernels, it may be impossible to keep an Arch Linux install up-to-date in such an environment. Linux 2.6.32, used by OpenVZ 6, is not supported by systemd since version 205 (and will not work with systemd-212 or higher). OpenVZ does sometimes backport newer kernel features into its kernel, but as of 2018-06-27, a fresh installation of Arch does not work on OpenVZ 6 kernel version 2.6.32-042stab131.1 . Arch can be installed on OpenVZ 7, with [[#Preparing the Arch build for use on an OpenVZ 7 container|a minor workaround]], as of OpenVZ 7 kernel version 3.10.0-693-21.1.vz7.48.2 .}}<br />
<br />
== Official Arch Linux cloud image ==<br />
<br />
Arch Linux provides a official cloud image as part of the [https://gitlab.archlinux.org/archlinux/arch-boxes arch-boxes project]. The image comes with [[Cloud-init]] preinstalled and should work with most cloud providers.<br />
<br />
The image can be downloaded from the mirrors under the {{ic|images}} directory. Instructions for tested providers is listed below:<br />
<br />
{| class="wikitable"<br />
! Provider !! Locations !! Note<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || Global ||<br />
# Find the cloud image on a mirror, ex: {{ic|https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Add the image as a custom image by [https://www.digitalocean.com/docs/images/custom-images/quickstart/#upload-images importing it]<br />
# [https://www.digitalocean.com/docs/images/custom-images/quickstart/#create-droplets-from-custom-images Create a new VM from the custom image]<br />
# SSH to the VM: {{ic|ssh root@<ip>}}<br />
|-<br />
| [https://www.hetzner.com/cloud Hetzner Cloud] || Nuremberg, Falkenstein (Germany), Helsinki (Finland) ||<br />
# Create a new VM with this user data:{{bc|#cloud-config<br><nowiki>vendor_data: {'enabled': false}</nowiki>}}<sup>The {{ic|vendor_data}} from Hetzner overrides the {{ic|distro}} and sets the default user to {{ic|root}} without setting {{ic|disable_root: false}}, meaning you can not login</sup><br />
# Boot the VM in rescue mode<br />
# SSH to the VM and download the cloud image from a mirror, ex: {{ic|curl -O https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Write the image to the disk: {{ic|qemu-img convert -f qcow2 -O raw Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 /dev/sda}}<br />
# Reboot the VM<br />
# SSH to the VM: {{ic|ssh arch@<ip>}}<br />
|-<br />
| [https://www.proxmox.com/ Proxmox] || N/A ||<br />
# Create a new VM<br />
# Select "Do not use any media" in OS section.<br />
# Remove created hard disk from your VM after VM creation completes.<br />
# Add the downloaded image to your VM using {{ic|qm importdisk}}, ex:<br> {{ic|qm importdisk 100 Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 local}}<br />
# Add a cloudinit drive and make your configurations in Cloud-Init section.<br />
# Start the VM!<br />
|-<br />
|}<br />
<br />
== Providers that offer Arch Linux ==<br />
<br />
{{Style|Inconsistency, some language issues}}<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|This list is for providers with a convenient Arch Linux template. Using Arch on other providers is possible but requires more work. Example methods include: <br />
* Loading custom disc images (requires hardware virtualization such as in Xen or KVM), <br />
** Ex the official [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Arch cloud image]<br />
* [[Installation guide|Installing under chroot]], for example with the help of the [https://gitlab.com/drizzt/vps2arch/ vps2arch] script (it will download the latest iso; be particularly aware of the systemd 220/221 [https://github.com/systemd/systemd/issues/421 bug]), or <br />
* Following [[#Installing the latest Arch Linux on any OpenVZ container provider]] instructions, using rsync to synchronize Arch over the top of another distribution.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Archiso release !! Virtualization !! Locations !! Notes<br />
|-<br />
| [https://www.1984hosting.com/ 1984hosting.com] || 2016.x || Xen || Iceland (IS) || [https://www.1984hosting.com/product/vps/ Hardware] will provide any image you request, has Arch in default image list.<br />
|-<br />
| [https://4smart.cz/ 4smart.cz] || 2013.08 || OpenVZ || Prague, CZ || (Czech language site only) when updating system make sure you use [tredaelli-systemd] in pacman.conf (see [[Unofficial user repositories]]<br />
|-<br />
| [https://www.affinity.net.nz/ affinity.net.nz] || 2013.08.01 || KVM || Auckland, New Zealand (NZ) || IRC channel is #affinity on ircs.kiwicon.org<br />
|-<br />
| [https://www.atlantic.net/ Atlantic.Net] || 2016.03.01 || KVM || NYC/SF/Toronto/Dallas/Orlando, US & Canada || 100% SSD 1-click Arch Linux, ready in 30 seconds. It is also easy to update Arch to the current version because the pre-provisioned Arch image is relatively current.<br />
|-<br />
| [https://buyvm.net/ BuyVM] || 2017.08.01 || KVM || Buffalo, (US-NY); Las Vegas, (US-NV); Luxembourg, Germany (DE) || Cannot select Arch at purchase. Once purchased, use Stallion control panel to install Arch manually from ISO. <br />
|-<br />
| [https://cloudvip.be CloudVIP] || Latest || KVM || Brussels, Belgium || French site and support.<br />
|-<br />
| [https://coinshost.com/en/vps Coinshost] || 2015.04 || Xen || Zurich, Switzerland || Bitcoin and other cryptocurrencies accepted.<br />
|-<br />
| [https://cherry.host Cherry Host] || Latest || KVM || Santee, US-CA || Must submit a support ticket to get Arch installed.<br />
|-<br />
| [https://contabo.com Contabo] || Latest || KVM || Germany || Only place to get 500 GB for 7€ - Decent speed. Other cheaps plans add snapshots, which is useful if you VPS runs a rolling release distro.<br />
|-<br />
| [https://www.directvps.nl/ DirectVPS] || 2014.01.xx || OpenVZ || Amsterdam, NL; Rotterdam, NL || (Dutch language site only)<br />
|-<br />
| [https://www.edis.at/en/ Edis] || [https://www.edis.at/en/server/available-distributions-and-os 2019.02.01] || vServer, KVM, OpenVZ || [https://www.edis.at/en/hosting/international-server-locations Multiple international locations]. || Also offer dedicated server options as well as an "off-shore" location at the Isle of Man (IM). Requires mounting an Arch ISO for a full manual install.<br />
|-<br />
| [https://hetzner.com/cloud Hetzner] || 2020.06.01 || KVM || Nuremberg, DE; Falkenstein, DE; Helsinki, FI || You cannot choose Arch Linux directly on the order form. Order Ubuntu or something first, then go to ISO Images, mount Arch Linux, reboot server, and log in to web console to complete installation.<br />
|-<br />
| [https://www.gigatux.com/virtual.php GigaTux] || [https://www.gigatux.com/distro/ 2013.06.01] || Xen || Chicago, US-IL; Frankfurt, DE; London, GB; San Jose, US-CA || Currently, when changing to the US$ currency, the page breaks and it is not possible to provision a server.<br />
|-<br />
| [https://leapswitch.com Leapswitch Networks] || 2013.10.xx || OpenVZ/KVM || USA, India, Portugal, Spain, Ukraine, Germany || Arch Linux currently available in Control Panel for reinstall, not on order form. <br />
|-<br />
| [https://linevast.de Linevast.de] || Latest || OpenVZ, KVM || Germany || Arch Linux is possible on openvz and on KVM with the one click os installer. <br />
|-<br />
| [https://www.linode.com Linode] || [https://www.linode.com/distributions Latest] || KVM || [https://www.linode.com/speedtest/ Multiple US, London, Frankfurt, Tokyo, Singapore] || Linode instances are configured to run Arch's kernel by default. Linode provides custom kernels which can be selected in the manager settings. There are also community-supported kernels in the AUR, such as {{AUR|linux-linode}}.<br />
|-<br />
| [http://lylix.net/ LYLIX] || [http://lylix.net/archlinux 2014.01.xx]{{Dead link|2021|05|09|status=404}} || OpenVZ || Multiple US; Europe || 32-bit and 64-bit available <br />
|-<br />
| [https://www.netcup.eu/ Netcup] || 2020.09.01 || KVM || Germany (DE)|| German language: [https://www.netcup.de/ Netcup]<br />
|-<br />
| [https://www.medhahosting.com MedHaHosting ] || Latest || KVM || Buffalo, NY, USA; Atlanta, GA, USA; Chicago, IL, USA; Los Angeles, CA, USA || Arch Linux available on request. Many Linux and Windows hosting options. <br />
|-<br />
| [https://monovm.com MonoVM ] || Latest || VMware || USA - Canada - Netherlands - Germany - UK - France - Denmark || VMware Based VPS Server Provider. <br />
|-<br />
| [https://www.onepoundwebhosting.co.uk/ OnePoundWebHosting] || 2014.01 || Xen PV, Xen HVM || United Kingdom (UK) || They are a registrar too. Unable to verify server locations.<br />
|-<br />
| [https://www.ovh.com/us/vps/ OVH] || Latest || KVM || Beauharnois, Canada (CA); Frankfurt, Germany (DE); Gravelines, Stratsbourg, France (FR); Warsaw, Poland (PL); London, United Kingdom (UK) || Disable and remove {{pkg|dhcpcd}} from the standard image to avoid long delays from conflicts with systemd-networkd. The default /etc/locale.gen also needs to be fixed due to an init value from cloud-init followed by running {{ic|locale-gen}}. Can also disable and remove [[haveged]] now that it's obsolete.<br />
|-<br />
| [https://pacmanvps.com/ PacmanVPS] || 2014.01 || KVM || Canada (CA), Poland (PL) || Arch image is very old and PacmanVPS repos are broken. Not possible to update Arch. Site appears unmaintained.<br />
|-<br />
| [https://www.proplay.de/ Proplay] || Latest || OpenVZ, KVM || Germany (DE) || (German language site only)<br />
|-<br />
| [https://www.rackspace.com/cloud/servers Rackspace Cloud] || 2013.6 || Xen || [https://www.rackspace.com/whyrackspace/network/datacenters/ Multiple international locations]{{Dead link|2020|12|19|status=404}} || Billed per hour. Use their "next gen" VPSes (using the mycloud.rackspace.com panel); the Arch image on the first gen Rackspace VPSes is out of date.<br />
|-<br />
| [https://www.ramhost.us/ RamHost.us] || [https://www.ramhost.us/?page=news 2013.05.01] || OpenVZ, KVM || Los Angeles, US-CA; Great Britain (GB); Atlanta, US-GA; Germany (DE) || You can request a newer ISO on RamHost's IRC network.<br />
|-<br />
| [https://www.ramnode.com/ RamNode] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=48 2016.01.01] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=39 SSD and SSD Cached:] [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=52 KVM] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=50 Alblasserdam, NL; Atlanta, GA-US; Los Angeles, CA-US; New York, NY-US; Seattle, WA-US] || You can request Host/CPU passthrough with KVM service.[https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=66] Frequent use of discount promotions.[https://twitter.com/search?q=ramnode%20code&src=typd], Must install Arch manually from an ISO using VNC viewer.<br />
|-<br />
| [https://www.rosehosting.com/ RoseHosting] || Latest || OpenVZ, KVM || St. Louis, Missouri, USA || SSD powered hosting plans with free fully-managed 24/7 support. No unmanaged VPS offerings.<br />
|-<br />
| [https://www.seedvps.com/ SeedVPS] || Latest || OpenVZ, KVM || Amsterdam, Netherlands || Linux VPS and Windows VPS Hosting in The Netherlands (NL). Newer ISO can be requested by opening a support ticket.<br />
|-<br />
| [https://www.servercheap.net Server Cheap] || Latest || OpenVZ, KVM || Chicago, Illinois, USA || Arch Linux available on request. Windows, BSD, and many Linux distribution hosting options. <br />
|-<br />
| [https://skyhost.ru/ SkyHost] || Latest || LXC || Moscow, Yaroslavl, Russia || <br />
|-<br />
| [https://www.tilaa.com/ Tilaa] || 2016.03.01 || [https://www.tilaa.com/pages/vps/technology KVM]{{Dead link|2020|03|28|status=404}} || Amsterdam, NL ||<br />
|-<br />
| [https://www.transip.eu/ TransIP] || latest || [https://www.transip.eu/vps/vps-technology/ KVM] || Amsterdam, NL || For latest image, submit ticket. Also registrar.<br />
|-<br />
| [https://upcube.io upCUBE]{{Dead link|2021|05|09|status=domain name not resolved}} || Latest || Docker || Germany || Different prepared arch linux templates available<br />
|-<br />
| [https://virpus.com/ Virpus] || [https://virpus.com/linux-vps.php 2014.11.07] || Xen || Kansas City, US-KS; Los Angeles, US-CA || Arch is '''not''' offered as a choice when creating a server (even though the Arch logo is prominently featured on the site). As of 2018, the most recent version of Ubuntu offered is 14.04, and the limited-time promo code for new sign ups is over two years old. None of this generates much trust.<br />
|-<br />
| [https://www.virtualmaster.com/ Virtual Master] || 2012-08 || ?? || Prague, CZ ||<br />
|-<br />
| [https://vps6.net/ VPS6.NET] || 2013.01.xx || OpenVZ, Xen, HVM-ISO || [http://vps6.net/network/ Multiple US]; Frankfurt, DE; Bucharest, RO; Istanbul, TR || Registrar.<br />
|-<br />
| [https://www.vpsbg.eu/ VPSBG.eu] || 2013.10 || OpenVZ || [https://vpsbg.eu/en/index.php?page=vps-datacenter Sofia, Bulgaria] || Offshore VPS in Bulgaria - anonymous registrations and Bitcoin are accepted.<br />
|-<br />
| [https://www.vpscheap.net VPSCHEAP] || 2016.10 || NVM KVM || Dallas, TX, USA || Has one plan that allows you to select Arch Linux, but does not appear in any other plan, but available on request. The system is severely outdated. To fix it install archlinux-keyring, then run pacman -Syu.<br />
|-<br />
| [https://www.vpsserver.com/ VPSSERVER] || 2015.07 || KVM || Chicago, US-IL; Dallas, US-TX; Miami, US-FL; New York, US-NY; Silicon Valley, US-CA; Amsterdam, NL; Frankfurt, DE; London, UK || Currently the latest Arch Linux OS version we are providing is 2015.07 x64 and you cannot update the OS version to the new version.<br />
|-<br />
| [https://www.vultr.com/ Vultr] || Latest || KVM || [https://www.vultr.com/locations/ Multiple International locations] || When deploying a new server just select the Arch install ISO from Vultr ISO Library. Then just manually run through the standard [[Installation guide|Arch installation guide]].<br />
|-<br />
| [https://www.world4you.com/ World4You] || 2015.10.28 || OpenVZ || Austria (AT) || Internet hosting provider; quick setup; 24/7 support; shared web hosting; also CentOS, Debian, Ubuntu, Fedora and Arch OpenVZ servers; supports newest systemd (227 atm)<br />
|-<br />
| [http://www.xenvz.co.uk/ XenVZ] || 2009.12.07 || OpenVZ, Xen || United Kingdom (UK), United States (US) || [http://www.xenvz.co.uk/faq.php#use2 Hardware]<br />
|-<br />
| [https://zappiehost.com/ ZappieHost] || Latest || LXC || Auckland, New Zealand (NZ) || Hosted on redundant SSDs. Kernel 4.X using LXC<br />
|-<br />
| [https://www.misaka.io/ Misaka.io / zeptoVM] || Latest || KVM || [https://www.misaka.io/services/mc2 Multiple International locations] || Images are built every 24 hrs<br />
|-<br />
|}<br />
<br />
== Providers with Community provided Arch Linux support ==<br />
<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|Arch Linux is not officially supported by these providers. The images and scripts listed here are created by the community.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Installation Type !! Locations !! Notes<br />
|- <br />
| [https://aws.amazon.com/ Amazon Web Services] || [[Arch Linux AMIs for Amazon Web Services|Custom Images]] || Global ||<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Official Arch cloud image], [https://github.com/gh2o/digitalocean-debian-to-arch Conversion Script] or [https://github.com/robsonde/digitalocean_builder Custom Image] || Global || IPv6 does not work with custom images, but works with conversion script<br />
|-<br />
| [https://cloud.google.com/ Google Cloud Platform] || [https://github.com/GoogleCloudPlatform/compute-archlinux-image-builder Custom Image] || Global || <br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
=== KVM ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[QEMU#Preparing an (Arch) Linux guest]].<br />
<br />
=== OpenVZ ===<br />
<br />
==== Installing the latest Arch Linux on any OpenVZ container provider ====<br />
<br />
{{Warning|Please refer to the warning about the older kernel version and systemd at the top of the page, and note the [[#Preparing the Arch build for use on an OpenVZ 7 container|workaround for OpenVZ 7 below]].}}<br />
<br />
It is possible to directly copy an installation of Arch Linux over the top of a working OpenVZ VPS. This tutorial explains how to create a basic installation of Arch Linux with {{ic|pacstrap}} (as used in a standard install) and then replace the contents of a target VPS with it using [[rsync]].<br />
<br />
This process (with minor modification) also works to migrate existing Arch installations between various environments and has been confirmed to work in migrating from OpenVZ to Xen and from Xen to OpenVZ. For an install to Xen, other hardware-virtualized platforms, or even to physical hardware, extra steps (basically running {{ic|mkinitcpio}} and installing a [[boot loader]]) are needed.<br />
<br />
===== Prerequisites =====<br />
<br />
* A working Arch Linux installation<br />
** To keep things simple, it should match the architecture you want to install on your VPS (x86_64 or i686).<br />
** To build from other distributions, [[Archbootstrap|arch-bootstrap.sh]] can be used in place of {{ic|pacstrap}}.<br />
* The {{Pkg|arch-install-scripts}}, {{Pkg|rsync}}, and {{Pkg|openssh}} packages from the [[official repositories]]<br />
** SSH is not strictly required, but rsync over SSH is the method used here.<br />
* A VPS running any distribution, with {{ic|rsync}} and a working SSH server<br />
** Its architecture (x86_64 or i686) does not matter as long as the OpenVZ installation can support your target architecture.<br />
* OpenVZ's serial console feature (usually accessible via your provider's control panel)<br />
** Without this, any network configuration for the target VPS will have to be done immediately after the "Build" step below.<br />
<br />
===== Building a clean Arch Linux installation =====<br />
<br />
As root, build the installation (optionally replacing {{ic|build}} with your preferred target directory):<br />
<br />
# mkdir build<br />
# pacstrap -cd build<br />
<br />
Other tweaks for the {{ic|pacstrap}} command:<br />
<br />
*{{ic|-C custom-pacman-config.conf}} - Use a custom pacman configuration file. By default, {{ic|pacstrap}} builds according to your local pacman.conf. This determines the architecture (i686 or x86_64) of the build, the mirror list, etc.<br />
*{{ic|-G}} - Prevent {{ic|pacstrap}} from copying your system's pacman keyring to the new build. If you use this option, you will need to run {{ic|pacman-key --init}} and {{ic|pacman-key --populate archlinux}} in the [[#Configuration|Configuration]] step to set up the keyring.<br />
*{{ic|-M}} - Prevent {{ic|pacstrap}} from copying your system's pacman mirror list to the new build.<br />
*You can pass a list of packages to {{ic|pacstrap}} to add them to your install, instead of the default {{ic|base}} group. For example: {{ic|pacstrap -cd build base openssh dnsutils gnu-netcat traceroute vim}}<br />
<br />
====== Preparing the Arch build for use on an OpenVZ 7 container ======<br />
<br />
OpenVZ 7 will fail to start a container if some expected network configuration files do not exist. The easiest way to get around this is as follows:<br />
<br />
# Create the OpenVZ 7 container as Debian 8 (Debian 9 would probably work as well).<br />
# Create the required blank network configuration files inside the Arch build, as follows:<br />
# mkdir build/etc/network<br />
# touch build/etc/network/interfaces<br />
# mkdir -p build/etc/resolvconf/resolv.conf.d<br />
# touch build/etc/resolvconf/resolv.conf.d/base<br />
<br />
===== Replacing everything on the VPS with the Arch build =====<br />
<br />
Replace all files, directories, etc. on your target VPS with the contents of your {{ic|build}} directory (replacing "YOUR.VPS.IP.ADDRESS" below):<br />
<br />
{{Warning|Be careful with the following command. By design, {{ic|rsync}} is very destructive, especially with any of the {{ic|--delete}} options.}}<br />
<br />
# rsync -axH --numeric-ids --delete-delay -e ssh --stats -P build/ YOUR.VPS.IP.ADDRESS:/<br />
<br />
Explanation of options:<br />
<br />
* {{ic|-a}} - Required. Preserves timestamps, permissions, etc.<br />
* {{ic|--delete}} - Required. Deletes anything in the target that does not exist in the source<br />
* {{ic|-x}} - Important. Prevents the crossing of filesystem boundaries (other partitions, /dev, etc.) during the copy<br />
* {{ic|-H}} - Important. Preserves hardlinks<br />
* {{ic|--numeric-ids}} - Important. Does not assign user/group ownership of files based on matching user and group names and instead uses the numeric IDs directly, ensuring proper file ownership on the target system<br />
* {{ic|--delete-delay}} - Recommended. Enables alternate deletion mode which waits to delete anything until the synchronization is otherwise complete, which may reduce the risk of a slow transfer causing the target VPS to lock-up<br />
* {{ic|-e ssh}} - Recommended. Uses {{ic|rsync}} over SSH (recommended for simplicity compared to setting up an {{ic|rsync}} server)<br />
* {{ic|-P}} - Recommended. Shows partial progress information during transfer<br />
* {{ic|--stats}} - Recommended. Shows transfer statistics at the end<br />
<br />
===== Configuration =====<br />
<br />
# Reboot the VPS externally (using your provider's control panel, for example).<br />
# Using OpenVZ's serial console feature, configure the [[network]] and [[Installation_guide#Configure_the_system|basic system settings]] (ignoring fstab generation and arch-chroot steps).<br />
#* If you do not have access to the serial console feature, you will need to preconfigure your network settings before synchronizing Arch to the VPS.<br />
#* On some VPS configuration you will not have a gateway to connect to, here is an example [[netctl]] configuration for this setup. It configures static IP addresses and default routes on venet0 and uses Google Public DNS.<br />
{{hc|/etc/netctl/venet|2=<br />
Description='VPS venet connection'<br />
Interface=venet0<br />
Connection=ethernet<br />
<br />
IP=static<br />
Address=('192.0.2.42/32')<br />
Routes=('default')<br />
<br />
IP6=static<br />
Address6=('2001:db8::1234:5678/128')<br />
Routes6=('default')<br />
<br />
DNS=('2001:4860:4860::8888' '2001:4860:4860::8844' '8.8.8.8' '8.8.4.4')<br />
}}<br />
<br />
=== Xen ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[Xen]].</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Arch_Linux_on_a_VPS&diff=673237Arch Linux on a VPS2021-05-24T21:45:41Z<p>Thestinger: /* Providers that offer Arch Linux */ clarify removing obsolete haveged</p>
<hr />
<div>[[Category:Installation process]]<br />
[[Category:Virtualization]]<br />
[[ja:Arch Linux VPS]]<br />
[[zh-hans:Arch Linux on a VPS]]<br />
{{Related articles start}}<br />
{{Related|Server}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Virtual private server]]:<br />
<br />
:Virtual private server (VPS) is a term used by Internet hosting services to refer to a virtual machine. The term is used for emphasizing that the virtual machine, although running in software on the same physical computer as other customers' virtual machines, is in many respects functionally equivalent to a separate physical computer, is dedicated to the individual customer's needs, has the privacy of a separate physical computer, and can be configured to run server software.<br />
<br />
This article discusses the use of Arch Linux on Virtual Private Servers, and includes some fixes and installation instructions specific to VPSes.<br />
<br />
{{Warning|<br />
* Since many container-based virtualization environments rely on older kernels, it may be impossible to keep an Arch Linux install up-to-date in such an environment. Linux 2.6.32, used by OpenVZ 6, is not supported by systemd since version 205 (and will not work with systemd-212 or higher). OpenVZ does sometimes backport newer kernel features into its kernel, but as of 2018-06-27, a fresh installation of Arch does not work on OpenVZ 6 kernel version 2.6.32-042stab131.1 . Arch can be installed on OpenVZ 7, with [[#Preparing the Arch build for use on an OpenVZ 7 container|a minor workaround]], as of OpenVZ 7 kernel version 3.10.0-693-21.1.vz7.48.2 .}}<br />
<br />
== Official Arch Linux cloud image ==<br />
<br />
Arch Linux provides a official cloud image as part of the [https://gitlab.archlinux.org/archlinux/arch-boxes arch-boxes project]. The image comes with [[Cloud-init]] preinstalled and should work with most cloud providers.<br />
<br />
The image can be downloaded from the mirrors under the {{ic|images}} directory. Instructions for tested providers is listed below:<br />
<br />
{| class="wikitable"<br />
! Provider !! Locations !! Note<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || Global ||<br />
# Find the cloud image on a mirror, ex: {{ic|https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Add the image as a custom image by [https://www.digitalocean.com/docs/images/custom-images/quickstart/#upload-images importing it]<br />
# [https://www.digitalocean.com/docs/images/custom-images/quickstart/#create-droplets-from-custom-images Create a new VM from the custom image]<br />
# SSH to the VM: {{ic|ssh root@<ip>}}<br />
|-<br />
| [https://www.hetzner.com/cloud Hetzner Cloud] || Nuremberg, Falkenstein (Germany), Helsinki (Finland) ||<br />
# Create a new VM with this user data:{{bc|#cloud-config<br><nowiki>vendor_data: {'enabled': false}</nowiki>}}<sup>The {{ic|vendor_data}} from Hetzner overrides the {{ic|distro}} and sets the default user to {{ic|root}} without setting {{ic|disable_root: false}}, meaning you can not login</sup><br />
# Boot the VM in rescue mode<br />
# SSH to the VM and download the cloud image from a mirror, ex: {{ic|curl -O https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Write the image to the disk: {{ic|qemu-img convert -f qcow2 -O raw Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 /dev/sda}}<br />
# Reboot the VM<br />
# SSH to the VM: {{ic|ssh arch@<ip>}}<br />
|-<br />
| [https://www.proxmox.com/ Proxmox] || N/A ||<br />
# Create a new VM<br />
# Select "Do not use any media" in OS section.<br />
# Remove created hard disk from your VM after VM creation completes.<br />
# Add the downloaded image to your VM using {{ic|qm importdisk}}, ex:<br> {{ic|qm importdisk 100 Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 local}}<br />
# Add a cloudinit drive and make your configurations in Cloud-Init section.<br />
# Start the VM!<br />
|-<br />
|}<br />
<br />
== Providers that offer Arch Linux ==<br />
<br />
{{Style|Inconsistency, some language issues}}<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|This list is for providers with a convenient Arch Linux template. Using Arch on other providers is possible but requires more work. Example methods include: <br />
* Loading custom disc images (requires hardware virtualization such as in Xen or KVM), <br />
** Ex the official [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Arch cloud image]<br />
* [[Installation guide|Installing under chroot]], for example with the help of the [https://gitlab.com/drizzt/vps2arch/ vps2arch] script (it will download the latest iso; be particularly aware of the systemd 220/221 [https://github.com/systemd/systemd/issues/421 bug]), or <br />
* Following [[#Installing the latest Arch Linux on any OpenVZ container provider]] instructions, using rsync to synchronize Arch over the top of another distribution.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Archiso release !! Virtualization !! Locations !! Notes<br />
|-<br />
| [https://www.1984hosting.com/ 1984hosting.com] || 2016.x || Xen || Iceland (IS) || [https://www.1984hosting.com/product/vps/ Hardware] will provide any image you request, has Arch in default image list.<br />
|-<br />
| [https://4smart.cz/ 4smart.cz] || 2013.08 || OpenVZ || Prague, CZ || (Czech language site only) when updating system make sure you use [tredaelli-systemd] in pacman.conf (see [[Unofficial user repositories]]<br />
|-<br />
| [https://www.affinity.net.nz/ affinity.net.nz] || 2013.08.01 || KVM || Auckland, New Zealand (NZ) || IRC channel is #affinity on ircs.kiwicon.org<br />
|-<br />
| [https://www.atlantic.net/ Atlantic.Net] || 2016.03.01 || KVM || NYC/SF/Toronto/Dallas/Orlando, US & Canada || 100% SSD 1-click Arch Linux, ready in 30 seconds. It is also easy to update Arch to the current version because the pre-provisioned Arch image is relatively current.<br />
|-<br />
| [https://buyvm.net/ BuyVM] || 2017.08.01 || KVM || Buffalo, (US-NY); Las Vegas, (US-NV); Luxembourg, Germany (DE) || Cannot select Arch at purchase. Once purchased, use Stallion control panel to install Arch manually from ISO. <br />
|-<br />
| [https://cloudvip.be CloudVIP] || Latest || KVM || Brussels, Belgium || French site and support.<br />
|-<br />
| [https://coinshost.com/en/vps Coinshost] || 2015.04 || Xen || Zurich, Switzerland || Bitcoin and other cryptocurrencies accepted.<br />
|-<br />
| [https://cherry.host Cherry Host] || Latest || KVM || Santee, US-CA || Must submit a support ticket to get Arch installed.<br />
|-<br />
| [https://contabo.com Contabo] || Latest || KVM || Germany || Only place to get 500 GB for 7€ - Decent speed. Other cheaps plans add snapshots, which is useful if you VPS runs a rolling release distro.<br />
|-<br />
| [https://www.directvps.nl/ DirectVPS] || 2014.01.xx || OpenVZ || Amsterdam, NL; Rotterdam, NL || (Dutch language site only)<br />
|-<br />
| [https://www.edis.at/en/ Edis] || [https://www.edis.at/en/server/available-distributions-and-os 2019.02.01] || vServer, KVM, OpenVZ || [https://www.edis.at/en/hosting/international-server-locations Multiple international locations]. || Also offer dedicated server options as well as an "off-shore" location at the Isle of Man (IM). Requires mounting an Arch ISO for a full manual install.<br />
|-<br />
| [https://hetzner.com/cloud Hetzner] || 2020.06.01 || KVM || Nuremberg, DE; Falkenstein, DE; Helsinki, FI || You cannot choose Arch Linux directly on the order form. Order Ubuntu or something first, then go to ISO Images, mount Arch Linux, reboot server, and log in to web console to complete installation.<br />
|-<br />
| [https://www.gigatux.com/virtual.php GigaTux] || [https://www.gigatux.com/distro/ 2013.06.01] || Xen || Chicago, US-IL; Frankfurt, DE; London, GB; San Jose, US-CA || Currently, when changing to the US$ currency, the page breaks and it is not possible to provision a server.<br />
|-<br />
| [https://leapswitch.com Leapswitch Networks] || 2013.10.xx || OpenVZ/KVM || USA, India, Portugal, Spain, Ukraine, Germany || Arch Linux currently available in Control Panel for reinstall, not on order form. <br />
|-<br />
| [https://linevast.de Linevast.de] || Latest || OpenVZ, KVM || Germany || Arch Linux is possible on openvz and on KVM with the one click os installer. <br />
|-<br />
| [https://www.linode.com Linode] || [https://www.linode.com/distributions Latest] || KVM || [https://www.linode.com/speedtest/ Multiple US, London, Frankfurt, Tokyo, Singapore] || Linode instances are configured to run Arch's kernel by default. Linode provides custom kernels which can be selected in the manager settings. There are also community-supported kernels in the AUR, such as {{AUR|linux-linode}}.<br />
|-<br />
| [http://lylix.net/ LYLIX] || [http://lylix.net/archlinux 2014.01.xx]{{Dead link|2021|05|09|status=404}} || OpenVZ || Multiple US; Europe || 32-bit and 64-bit available <br />
|-<br />
| [https://www.netcup.eu/ Netcup] || 2020.09.01 || KVM || Germany (DE)|| German language: [https://www.netcup.de/ Netcup]<br />
|-<br />
| [https://www.medhahosting.com MedHaHosting ] || Latest || KVM || Buffalo, NY, USA; Atlanta, GA, USA; Chicago, IL, USA; Los Angeles, CA, USA || Arch Linux available on request. Many Linux and Windows hosting options. <br />
|-<br />
| [https://monovm.com MonoVM ] || Latest || VMware || USA - Canada - Netherlands - Germany - UK - France - Denmark || VMware Based VPS Server Provider. <br />
|-<br />
| [https://www.onepoundwebhosting.co.uk/ OnePoundWebHosting] || 2014.01 || Xen PV, Xen HVM || United Kingdom (UK) || They are a registrar too. Unable to verify server locations.<br />
|-<br />
| [https://www.ovh.com/us/vps/ OVH] || Latest || KVM || Beauharnois, Canada (CA); Frankfurt, Germany (DE); Gravelines, Stratsbourg, France (FR); Warsaw, Poland (PL); London, United Kingdom (UK) || Disable and remove {{pkg|dhcpcd}} from the standard image to avoid long delays from conflicts with systemd-networkd. Can also disable and remove [[haveged]] now that it's obsolete.<br />
|-<br />
| [https://pacmanvps.com/ PacmanVPS] || 2014.01 || KVM || Canada (CA), Poland (PL) || Arch image is very old and PacmanVPS repos are broken. Not possible to update Arch. Site appears unmaintained.<br />
|-<br />
| [https://www.proplay.de/ Proplay] || Latest || OpenVZ, KVM || Germany (DE) || (German language site only)<br />
|-<br />
| [https://www.rackspace.com/cloud/servers Rackspace Cloud] || 2013.6 || Xen || [https://www.rackspace.com/whyrackspace/network/datacenters/ Multiple international locations]{{Dead link|2020|12|19|status=404}} || Billed per hour. Use their "next gen" VPSes (using the mycloud.rackspace.com panel); the Arch image on the first gen Rackspace VPSes is out of date.<br />
|-<br />
| [https://www.ramhost.us/ RamHost.us] || [https://www.ramhost.us/?page=news 2013.05.01] || OpenVZ, KVM || Los Angeles, US-CA; Great Britain (GB); Atlanta, US-GA; Germany (DE) || You can request a newer ISO on RamHost's IRC network.<br />
|-<br />
| [https://www.ramnode.com/ RamNode] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=48 2016.01.01] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=39 SSD and SSD Cached:] [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=52 KVM] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=50 Alblasserdam, NL; Atlanta, GA-US; Los Angeles, CA-US; New York, NY-US; Seattle, WA-US] || You can request Host/CPU passthrough with KVM service.[https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=66] Frequent use of discount promotions.[https://twitter.com/search?q=ramnode%20code&src=typd], Must install Arch manually from an ISO using VNC viewer.<br />
|-<br />
| [https://www.rosehosting.com/ RoseHosting] || Latest || OpenVZ, KVM || St. Louis, Missouri, USA || SSD powered hosting plans with free fully-managed 24/7 support. No unmanaged VPS offerings.<br />
|-<br />
| [https://www.seedvps.com/ SeedVPS] || Latest || OpenVZ, KVM || Amsterdam, Netherlands || Linux VPS and Windows VPS Hosting in The Netherlands (NL). Newer ISO can be requested by opening a support ticket.<br />
|-<br />
| [https://www.servercheap.net Server Cheap] || Latest || OpenVZ, KVM || Chicago, Illinois, USA || Arch Linux available on request. Windows, BSD, and many Linux distribution hosting options. <br />
|-<br />
| [https://skyhost.ru/ SkyHost] || Latest || LXC || Moscow, Yaroslavl, Russia || <br />
|-<br />
| [https://www.tilaa.com/ Tilaa] || 2016.03.01 || [https://www.tilaa.com/pages/vps/technology KVM]{{Dead link|2020|03|28|status=404}} || Amsterdam, NL ||<br />
|-<br />
| [https://www.transip.eu/ TransIP] || latest || [https://www.transip.eu/vps/vps-technology/ KVM] || Amsterdam, NL || For latest image, submit ticket. Also registrar.<br />
|-<br />
| [https://upcube.io upCUBE]{{Dead link|2021|05|09|status=domain name not resolved}} || Latest || Docker || Germany || Different prepared arch linux templates available<br />
|-<br />
| [https://virpus.com/ Virpus] || [https://virpus.com/linux-vps.php 2014.11.07] || Xen || Kansas City, US-KS; Los Angeles, US-CA || Arch is '''not''' offered as a choice when creating a server (even though the Arch logo is prominently featured on the site). As of 2018, the most recent version of Ubuntu offered is 14.04, and the limited-time promo code for new sign ups is over two years old. None of this generates much trust.<br />
|-<br />
| [https://www.virtualmaster.com/ Virtual Master] || 2012-08 || ?? || Prague, CZ ||<br />
|-<br />
| [https://vps6.net/ VPS6.NET] || 2013.01.xx || OpenVZ, Xen, HVM-ISO || [http://vps6.net/network/ Multiple US]; Frankfurt, DE; Bucharest, RO; Istanbul, TR || Registrar.<br />
|-<br />
| [https://www.vpsbg.eu/ VPSBG.eu] || 2013.10 || OpenVZ || [https://vpsbg.eu/en/index.php?page=vps-datacenter Sofia, Bulgaria] || Offshore VPS in Bulgaria - anonymous registrations and Bitcoin are accepted.<br />
|-<br />
| [https://www.vpscheap.net VPSCHEAP] || 2016.10 || NVM KVM || Dallas, TX, USA || Has one plan that allows you to select Arch Linux, but does not appear in any other plan, but available on request. The system is severely outdated. To fix it install archlinux-keyring, then run pacman -Syu.<br />
|-<br />
| [https://www.vpsserver.com/ VPSSERVER] || 2015.07 || KVM || Chicago, US-IL; Dallas, US-TX; Miami, US-FL; New York, US-NY; Silicon Valley, US-CA; Amsterdam, NL; Frankfurt, DE; London, UK || Currently the latest Arch Linux OS version we are providing is 2015.07 x64 and you cannot update the OS version to the new version.<br />
|-<br />
| [https://www.vultr.com/ Vultr] || Latest || KVM || [https://www.vultr.com/locations/ Multiple International locations] || When deploying a new server just select the Arch install ISO from Vultr ISO Library. Then just manually run through the standard [[Installation guide|Arch installation guide]].<br />
|-<br />
| [https://www.world4you.com/ World4You] || 2015.10.28 || OpenVZ || Austria (AT) || Internet hosting provider; quick setup; 24/7 support; shared web hosting; also CentOS, Debian, Ubuntu, Fedora and Arch OpenVZ servers; supports newest systemd (227 atm)<br />
|-<br />
| [http://www.xenvz.co.uk/ XenVZ] || 2009.12.07 || OpenVZ, Xen || United Kingdom (UK), United States (US) || [http://www.xenvz.co.uk/faq.php#use2 Hardware]<br />
|-<br />
| [https://zappiehost.com/ ZappieHost] || Latest || LXC || Auckland, New Zealand (NZ) || Hosted on redundant SSDs. Kernel 4.X using LXC<br />
|-<br />
| [https://www.misaka.io/ Misaka.io / zeptoVM] || Latest || KVM || [https://www.misaka.io/services/mc2 Multiple International locations] || Images are built every 24 hrs<br />
|-<br />
|}<br />
<br />
== Providers with Community provided Arch Linux support ==<br />
<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|Arch Linux is not officially supported by these providers. The images and scripts listed here are created by the community.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Installation Type !! Locations !! Notes<br />
|- <br />
| [https://aws.amazon.com/ Amazon Web Services] || [[Arch Linux AMIs for Amazon Web Services|Custom Images]] || Global ||<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Official Arch cloud image], [https://github.com/gh2o/digitalocean-debian-to-arch Conversion Script] or [https://github.com/robsonde/digitalocean_builder Custom Image] || Global || IPv6 does not work with custom images, but works with conversion script<br />
|-<br />
| [https://cloud.google.com/ Google Cloud Platform] || [https://github.com/GoogleCloudPlatform/compute-archlinux-image-builder Custom Image] || Global || <br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
=== KVM ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[QEMU#Preparing an (Arch) Linux guest]].<br />
<br />
=== OpenVZ ===<br />
<br />
==== Installing the latest Arch Linux on any OpenVZ container provider ====<br />
<br />
{{Warning|Please refer to the warning about the older kernel version and systemd at the top of the page, and note the [[#Preparing the Arch build for use on an OpenVZ 7 container|workaround for OpenVZ 7 below]].}}<br />
<br />
It is possible to directly copy an installation of Arch Linux over the top of a working OpenVZ VPS. This tutorial explains how to create a basic installation of Arch Linux with {{ic|pacstrap}} (as used in a standard install) and then replace the contents of a target VPS with it using [[rsync]].<br />
<br />
This process (with minor modification) also works to migrate existing Arch installations between various environments and has been confirmed to work in migrating from OpenVZ to Xen and from Xen to OpenVZ. For an install to Xen, other hardware-virtualized platforms, or even to physical hardware, extra steps (basically running {{ic|mkinitcpio}} and installing a [[boot loader]]) are needed.<br />
<br />
===== Prerequisites =====<br />
<br />
* A working Arch Linux installation<br />
** To keep things simple, it should match the architecture you want to install on your VPS (x86_64 or i686).<br />
** To build from other distributions, [[Archbootstrap|arch-bootstrap.sh]] can be used in place of {{ic|pacstrap}}.<br />
* The {{Pkg|arch-install-scripts}}, {{Pkg|rsync}}, and {{Pkg|openssh}} packages from the [[official repositories]]<br />
** SSH is not strictly required, but rsync over SSH is the method used here.<br />
* A VPS running any distribution, with {{ic|rsync}} and a working SSH server<br />
** Its architecture (x86_64 or i686) does not matter as long as the OpenVZ installation can support your target architecture.<br />
* OpenVZ's serial console feature (usually accessible via your provider's control panel)<br />
** Without this, any network configuration for the target VPS will have to be done immediately after the "Build" step below.<br />
<br />
===== Building a clean Arch Linux installation =====<br />
<br />
As root, build the installation (optionally replacing {{ic|build}} with your preferred target directory):<br />
<br />
# mkdir build<br />
# pacstrap -cd build<br />
<br />
Other tweaks for the {{ic|pacstrap}} command:<br />
<br />
*{{ic|-C custom-pacman-config.conf}} - Use a custom pacman configuration file. By default, {{ic|pacstrap}} builds according to your local pacman.conf. This determines the architecture (i686 or x86_64) of the build, the mirror list, etc.<br />
*{{ic|-G}} - Prevent {{ic|pacstrap}} from copying your system's pacman keyring to the new build. If you use this option, you will need to run {{ic|pacman-key --init}} and {{ic|pacman-key --populate archlinux}} in the [[#Configuration|Configuration]] step to set up the keyring.<br />
*{{ic|-M}} - Prevent {{ic|pacstrap}} from copying your system's pacman mirror list to the new build.<br />
*You can pass a list of packages to {{ic|pacstrap}} to add them to your install, instead of the default {{ic|base}} group. For example: {{ic|pacstrap -cd build base openssh dnsutils gnu-netcat traceroute vim}}<br />
<br />
====== Preparing the Arch build for use on an OpenVZ 7 container ======<br />
<br />
OpenVZ 7 will fail to start a container if some expected network configuration files do not exist. The easiest way to get around this is as follows:<br />
<br />
# Create the OpenVZ 7 container as Debian 8 (Debian 9 would probably work as well).<br />
# Create the required blank network configuration files inside the Arch build, as follows:<br />
# mkdir build/etc/network<br />
# touch build/etc/network/interfaces<br />
# mkdir -p build/etc/resolvconf/resolv.conf.d<br />
# touch build/etc/resolvconf/resolv.conf.d/base<br />
<br />
===== Replacing everything on the VPS with the Arch build =====<br />
<br />
Replace all files, directories, etc. on your target VPS with the contents of your {{ic|build}} directory (replacing "YOUR.VPS.IP.ADDRESS" below):<br />
<br />
{{Warning|Be careful with the following command. By design, {{ic|rsync}} is very destructive, especially with any of the {{ic|--delete}} options.}}<br />
<br />
# rsync -axH --numeric-ids --delete-delay -e ssh --stats -P build/ YOUR.VPS.IP.ADDRESS:/<br />
<br />
Explanation of options:<br />
<br />
* {{ic|-a}} - Required. Preserves timestamps, permissions, etc.<br />
* {{ic|--delete}} - Required. Deletes anything in the target that does not exist in the source<br />
* {{ic|-x}} - Important. Prevents the crossing of filesystem boundaries (other partitions, /dev, etc.) during the copy<br />
* {{ic|-H}} - Important. Preserves hardlinks<br />
* {{ic|--numeric-ids}} - Important. Does not assign user/group ownership of files based on matching user and group names and instead uses the numeric IDs directly, ensuring proper file ownership on the target system<br />
* {{ic|--delete-delay}} - Recommended. Enables alternate deletion mode which waits to delete anything until the synchronization is otherwise complete, which may reduce the risk of a slow transfer causing the target VPS to lock-up<br />
* {{ic|-e ssh}} - Recommended. Uses {{ic|rsync}} over SSH (recommended for simplicity compared to setting up an {{ic|rsync}} server)<br />
* {{ic|-P}} - Recommended. Shows partial progress information during transfer<br />
* {{ic|--stats}} - Recommended. Shows transfer statistics at the end<br />
<br />
===== Configuration =====<br />
<br />
# Reboot the VPS externally (using your provider's control panel, for example).<br />
# Using OpenVZ's serial console feature, configure the [[network]] and [[Installation_guide#Configure_the_system|basic system settings]] (ignoring fstab generation and arch-chroot steps).<br />
#* If you do not have access to the serial console feature, you will need to preconfigure your network settings before synchronizing Arch to the VPS.<br />
#* On some VPS configuration you will not have a gateway to connect to, here is an example [[netctl]] configuration for this setup. It configures static IP addresses and default routes on venet0 and uses Google Public DNS.<br />
{{hc|/etc/netctl/venet|2=<br />
Description='VPS venet connection'<br />
Interface=venet0<br />
Connection=ethernet<br />
<br />
IP=static<br />
Address=('192.0.2.42/32')<br />
Routes=('default')<br />
<br />
IP6=static<br />
Address6=('2001:db8::1234:5678/128')<br />
Routes6=('default')<br />
<br />
DNS=('2001:4860:4860::8888' '2001:4860:4860::8844' '8.8.8.8' '8.8.4.4')<br />
}}<br />
<br />
=== Xen ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[Xen]].</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Arch_Linux_on_a_VPS&diff=673236Arch Linux on a VPS2021-05-24T21:45:07Z<p>Thestinger: /* Providers that offer Arch Linux */ OVH dropped Arch Linux images for dedicated servers but still has them for VPS. Also, added notes on fixing up some issues with their images.</p>
<hr />
<div>[[Category:Installation process]]<br />
[[Category:Virtualization]]<br />
[[ja:Arch Linux VPS]]<br />
[[zh-hans:Arch Linux on a VPS]]<br />
{{Related articles start}}<br />
{{Related|Server}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Virtual private server]]:<br />
<br />
:Virtual private server (VPS) is a term used by Internet hosting services to refer to a virtual machine. The term is used for emphasizing that the virtual machine, although running in software on the same physical computer as other customers' virtual machines, is in many respects functionally equivalent to a separate physical computer, is dedicated to the individual customer's needs, has the privacy of a separate physical computer, and can be configured to run server software.<br />
<br />
This article discusses the use of Arch Linux on Virtual Private Servers, and includes some fixes and installation instructions specific to VPSes.<br />
<br />
{{Warning|<br />
* Since many container-based virtualization environments rely on older kernels, it may be impossible to keep an Arch Linux install up-to-date in such an environment. Linux 2.6.32, used by OpenVZ 6, is not supported by systemd since version 205 (and will not work with systemd-212 or higher). OpenVZ does sometimes backport newer kernel features into its kernel, but as of 2018-06-27, a fresh installation of Arch does not work on OpenVZ 6 kernel version 2.6.32-042stab131.1 . Arch can be installed on OpenVZ 7, with [[#Preparing the Arch build for use on an OpenVZ 7 container|a minor workaround]], as of OpenVZ 7 kernel version 3.10.0-693-21.1.vz7.48.2 .}}<br />
<br />
== Official Arch Linux cloud image ==<br />
<br />
Arch Linux provides a official cloud image as part of the [https://gitlab.archlinux.org/archlinux/arch-boxes arch-boxes project]. The image comes with [[Cloud-init]] preinstalled and should work with most cloud providers.<br />
<br />
The image can be downloaded from the mirrors under the {{ic|images}} directory. Instructions for tested providers is listed below:<br />
<br />
{| class="wikitable"<br />
! Provider !! Locations !! Note<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || Global ||<br />
# Find the cloud image on a mirror, ex: {{ic|https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Add the image as a custom image by [https://www.digitalocean.com/docs/images/custom-images/quickstart/#upload-images importing it]<br />
# [https://www.digitalocean.com/docs/images/custom-images/quickstart/#create-droplets-from-custom-images Create a new VM from the custom image]<br />
# SSH to the VM: {{ic|ssh root@<ip>}}<br />
|-<br />
| [https://www.hetzner.com/cloud Hetzner Cloud] || Nuremberg, Falkenstein (Germany), Helsinki (Finland) ||<br />
# Create a new VM with this user data:{{bc|#cloud-config<br><nowiki>vendor_data: {'enabled': false}</nowiki>}}<sup>The {{ic|vendor_data}} from Hetzner overrides the {{ic|distro}} and sets the default user to {{ic|root}} without setting {{ic|disable_root: false}}, meaning you can not login</sup><br />
# Boot the VM in rescue mode<br />
# SSH to the VM and download the cloud image from a mirror, ex: {{ic|curl -O https://mirror.pkgbuild.com/images/v20210315.17387/Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2}}<br />
# Write the image to the disk: {{ic|qemu-img convert -f qcow2 -O raw Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 /dev/sda}}<br />
# Reboot the VM<br />
# SSH to the VM: {{ic|ssh arch@<ip>}}<br />
|-<br />
| [https://www.proxmox.com/ Proxmox] || N/A ||<br />
# Create a new VM<br />
# Select "Do not use any media" in OS section.<br />
# Remove created hard disk from your VM after VM creation completes.<br />
# Add the downloaded image to your VM using {{ic|qm importdisk}}, ex:<br> {{ic|qm importdisk 100 Arch-Linux-x86_64-cloudimg-20210315.17387.qcow2 local}}<br />
# Add a cloudinit drive and make your configurations in Cloud-Init section.<br />
# Start the VM!<br />
|-<br />
|}<br />
<br />
== Providers that offer Arch Linux ==<br />
<br />
{{Style|Inconsistency, some language issues}}<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|This list is for providers with a convenient Arch Linux template. Using Arch on other providers is possible but requires more work. Example methods include: <br />
* Loading custom disc images (requires hardware virtualization such as in Xen or KVM), <br />
** Ex the official [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Arch cloud image]<br />
* [[Installation guide|Installing under chroot]], for example with the help of the [https://gitlab.com/drizzt/vps2arch/ vps2arch] script (it will download the latest iso; be particularly aware of the systemd 220/221 [https://github.com/systemd/systemd/issues/421 bug]), or <br />
* Following [[#Installing the latest Arch Linux on any OpenVZ container provider]] instructions, using rsync to synchronize Arch over the top of another distribution.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Archiso release !! Virtualization !! Locations !! Notes<br />
|-<br />
| [https://www.1984hosting.com/ 1984hosting.com] || 2016.x || Xen || Iceland (IS) || [https://www.1984hosting.com/product/vps/ Hardware] will provide any image you request, has Arch in default image list.<br />
|-<br />
| [https://4smart.cz/ 4smart.cz] || 2013.08 || OpenVZ || Prague, CZ || (Czech language site only) when updating system make sure you use [tredaelli-systemd] in pacman.conf (see [[Unofficial user repositories]]<br />
|-<br />
| [https://www.affinity.net.nz/ affinity.net.nz] || 2013.08.01 || KVM || Auckland, New Zealand (NZ) || IRC channel is #affinity on ircs.kiwicon.org<br />
|-<br />
| [https://www.atlantic.net/ Atlantic.Net] || 2016.03.01 || KVM || NYC/SF/Toronto/Dallas/Orlando, US & Canada || 100% SSD 1-click Arch Linux, ready in 30 seconds. It is also easy to update Arch to the current version because the pre-provisioned Arch image is relatively current.<br />
|-<br />
| [https://buyvm.net/ BuyVM] || 2017.08.01 || KVM || Buffalo, (US-NY); Las Vegas, (US-NV); Luxembourg, Germany (DE) || Cannot select Arch at purchase. Once purchased, use Stallion control panel to install Arch manually from ISO. <br />
|-<br />
| [https://cloudvip.be CloudVIP] || Latest || KVM || Brussels, Belgium || French site and support.<br />
|-<br />
| [https://coinshost.com/en/vps Coinshost] || 2015.04 || Xen || Zurich, Switzerland || Bitcoin and other cryptocurrencies accepted.<br />
|-<br />
| [https://cherry.host Cherry Host] || Latest || KVM || Santee, US-CA || Must submit a support ticket to get Arch installed.<br />
|-<br />
| [https://contabo.com Contabo] || Latest || KVM || Germany || Only place to get 500 GB for 7€ - Decent speed. Other cheaps plans add snapshots, which is useful if you VPS runs a rolling release distro.<br />
|-<br />
| [https://www.directvps.nl/ DirectVPS] || 2014.01.xx || OpenVZ || Amsterdam, NL; Rotterdam, NL || (Dutch language site only)<br />
|-<br />
| [https://www.edis.at/en/ Edis] || [https://www.edis.at/en/server/available-distributions-and-os 2019.02.01] || vServer, KVM, OpenVZ || [https://www.edis.at/en/hosting/international-server-locations Multiple international locations]. || Also offer dedicated server options as well as an "off-shore" location at the Isle of Man (IM). Requires mounting an Arch ISO for a full manual install.<br />
|-<br />
| [https://hetzner.com/cloud Hetzner] || 2020.06.01 || KVM || Nuremberg, DE; Falkenstein, DE; Helsinki, FI || You cannot choose Arch Linux directly on the order form. Order Ubuntu or something first, then go to ISO Images, mount Arch Linux, reboot server, and log in to web console to complete installation.<br />
|-<br />
| [https://www.gigatux.com/virtual.php GigaTux] || [https://www.gigatux.com/distro/ 2013.06.01] || Xen || Chicago, US-IL; Frankfurt, DE; London, GB; San Jose, US-CA || Currently, when changing to the US$ currency, the page breaks and it is not possible to provision a server.<br />
|-<br />
| [https://leapswitch.com Leapswitch Networks] || 2013.10.xx || OpenVZ/KVM || USA, India, Portugal, Spain, Ukraine, Germany || Arch Linux currently available in Control Panel for reinstall, not on order form. <br />
|-<br />
| [https://linevast.de Linevast.de] || Latest || OpenVZ, KVM || Germany || Arch Linux is possible on openvz and on KVM with the one click os installer. <br />
|-<br />
| [https://www.linode.com Linode] || [https://www.linode.com/distributions Latest] || KVM || [https://www.linode.com/speedtest/ Multiple US, London, Frankfurt, Tokyo, Singapore] || Linode instances are configured to run Arch's kernel by default. Linode provides custom kernels which can be selected in the manager settings. There are also community-supported kernels in the AUR, such as {{AUR|linux-linode}}.<br />
|-<br />
| [http://lylix.net/ LYLIX] || [http://lylix.net/archlinux 2014.01.xx]{{Dead link|2021|05|09|status=404}} || OpenVZ || Multiple US; Europe || 32-bit and 64-bit available <br />
|-<br />
| [https://www.netcup.eu/ Netcup] || 2020.09.01 || KVM || Germany (DE)|| German language: [https://www.netcup.de/ Netcup]<br />
|-<br />
| [https://www.medhahosting.com MedHaHosting ] || Latest || KVM || Buffalo, NY, USA; Atlanta, GA, USA; Chicago, IL, USA; Los Angeles, CA, USA || Arch Linux available on request. Many Linux and Windows hosting options. <br />
|-<br />
| [https://monovm.com MonoVM ] || Latest || VMware || USA - Canada - Netherlands - Germany - UK - France - Denmark || VMware Based VPS Server Provider. <br />
|-<br />
| [https://www.onepoundwebhosting.co.uk/ OnePoundWebHosting] || 2014.01 || Xen PV, Xen HVM || United Kingdom (UK) || They are a registrar too. Unable to verify server locations.<br />
|-<br />
| [https://www.ovh.com/us/vps/ OVH] || Latest || KVM || Beauharnois, Canada (CA); Frankfurt, Germany (DE); Gravelines, Stratsbourg, France (FR); Warsaw, Poland (PL); London, United Kingdom (UK) || Disable and remove {{pkg|dhcpcd}} from the standard image to avoid long delays from conflicts with systemd-networkd. Can also remove [[haveged]] now that it's obsolete.<br />
|-<br />
| [https://pacmanvps.com/ PacmanVPS] || 2014.01 || KVM || Canada (CA), Poland (PL) || Arch image is very old and PacmanVPS repos are broken. Not possible to update Arch. Site appears unmaintained.<br />
|-<br />
| [https://www.proplay.de/ Proplay] || Latest || OpenVZ, KVM || Germany (DE) || (German language site only)<br />
|-<br />
| [https://www.rackspace.com/cloud/servers Rackspace Cloud] || 2013.6 || Xen || [https://www.rackspace.com/whyrackspace/network/datacenters/ Multiple international locations]{{Dead link|2020|12|19|status=404}} || Billed per hour. Use their "next gen" VPSes (using the mycloud.rackspace.com panel); the Arch image on the first gen Rackspace VPSes is out of date.<br />
|-<br />
| [https://www.ramhost.us/ RamHost.us] || [https://www.ramhost.us/?page=news 2013.05.01] || OpenVZ, KVM || Los Angeles, US-CA; Great Britain (GB); Atlanta, US-GA; Germany (DE) || You can request a newer ISO on RamHost's IRC network.<br />
|-<br />
| [https://www.ramnode.com/ RamNode] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=48 2016.01.01] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=39 SSD and SSD Cached:] [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=52 KVM] || [https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=50 Alblasserdam, NL; Atlanta, GA-US; Los Angeles, CA-US; New York, NY-US; Seattle, WA-US] || You can request Host/CPU passthrough with KVM service.[https://clientarea.ramnode.com/knowledgebase.php?action=displayarticle&id=66] Frequent use of discount promotions.[https://twitter.com/search?q=ramnode%20code&src=typd], Must install Arch manually from an ISO using VNC viewer.<br />
|-<br />
| [https://www.rosehosting.com/ RoseHosting] || Latest || OpenVZ, KVM || St. Louis, Missouri, USA || SSD powered hosting plans with free fully-managed 24/7 support. No unmanaged VPS offerings.<br />
|-<br />
| [https://www.seedvps.com/ SeedVPS] || Latest || OpenVZ, KVM || Amsterdam, Netherlands || Linux VPS and Windows VPS Hosting in The Netherlands (NL). Newer ISO can be requested by opening a support ticket.<br />
|-<br />
| [https://www.servercheap.net Server Cheap] || Latest || OpenVZ, KVM || Chicago, Illinois, USA || Arch Linux available on request. Windows, BSD, and many Linux distribution hosting options. <br />
|-<br />
| [https://skyhost.ru/ SkyHost] || Latest || LXC || Moscow, Yaroslavl, Russia || <br />
|-<br />
| [https://www.tilaa.com/ Tilaa] || 2016.03.01 || [https://www.tilaa.com/pages/vps/technology KVM]{{Dead link|2020|03|28|status=404}} || Amsterdam, NL ||<br />
|-<br />
| [https://www.transip.eu/ TransIP] || latest || [https://www.transip.eu/vps/vps-technology/ KVM] || Amsterdam, NL || For latest image, submit ticket. Also registrar.<br />
|-<br />
| [https://upcube.io upCUBE]{{Dead link|2021|05|09|status=domain name not resolved}} || Latest || Docker || Germany || Different prepared arch linux templates available<br />
|-<br />
| [https://virpus.com/ Virpus] || [https://virpus.com/linux-vps.php 2014.11.07] || Xen || Kansas City, US-KS; Los Angeles, US-CA || Arch is '''not''' offered as a choice when creating a server (even though the Arch logo is prominently featured on the site). As of 2018, the most recent version of Ubuntu offered is 14.04, and the limited-time promo code for new sign ups is over two years old. None of this generates much trust.<br />
|-<br />
| [https://www.virtualmaster.com/ Virtual Master] || 2012-08 || ?? || Prague, CZ ||<br />
|-<br />
| [https://vps6.net/ VPS6.NET] || 2013.01.xx || OpenVZ, Xen, HVM-ISO || [http://vps6.net/network/ Multiple US]; Frankfurt, DE; Bucharest, RO; Istanbul, TR || Registrar.<br />
|-<br />
| [https://www.vpsbg.eu/ VPSBG.eu] || 2013.10 || OpenVZ || [https://vpsbg.eu/en/index.php?page=vps-datacenter Sofia, Bulgaria] || Offshore VPS in Bulgaria - anonymous registrations and Bitcoin are accepted.<br />
|-<br />
| [https://www.vpscheap.net VPSCHEAP] || 2016.10 || NVM KVM || Dallas, TX, USA || Has one plan that allows you to select Arch Linux, but does not appear in any other plan, but available on request. The system is severely outdated. To fix it install archlinux-keyring, then run pacman -Syu.<br />
|-<br />
| [https://www.vpsserver.com/ VPSSERVER] || 2015.07 || KVM || Chicago, US-IL; Dallas, US-TX; Miami, US-FL; New York, US-NY; Silicon Valley, US-CA; Amsterdam, NL; Frankfurt, DE; London, UK || Currently the latest Arch Linux OS version we are providing is 2015.07 x64 and you cannot update the OS version to the new version.<br />
|-<br />
| [https://www.vultr.com/ Vultr] || Latest || KVM || [https://www.vultr.com/locations/ Multiple International locations] || When deploying a new server just select the Arch install ISO from Vultr ISO Library. Then just manually run through the standard [[Installation guide|Arch installation guide]].<br />
|-<br />
| [https://www.world4you.com/ World4You] || 2015.10.28 || OpenVZ || Austria (AT) || Internet hosting provider; quick setup; 24/7 support; shared web hosting; also CentOS, Debian, Ubuntu, Fedora and Arch OpenVZ servers; supports newest systemd (227 atm)<br />
|-<br />
| [http://www.xenvz.co.uk/ XenVZ] || 2009.12.07 || OpenVZ, Xen || United Kingdom (UK), United States (US) || [http://www.xenvz.co.uk/faq.php#use2 Hardware]<br />
|-<br />
| [https://zappiehost.com/ ZappieHost] || Latest || LXC || Auckland, New Zealand (NZ) || Hosted on redundant SSDs. Kernel 4.X using LXC<br />
|-<br />
| [https://www.misaka.io/ Misaka.io / zeptoVM] || Latest || KVM || [https://www.misaka.io/services/mc2 Multiple International locations] || Images are built every 24 hrs<br />
|-<br />
|}<br />
<br />
== Providers with Community provided Arch Linux support ==<br />
<br />
{{Warning|We cannot vouch for the honesty or quality of any provider. Please conduct due diligence before ordering.}}<br />
{{Note|Arch Linux is not officially supported by these providers. The images and scripts listed here are created by the community.}}<br />
<br />
{| class="wikitable"<br />
! Provider !! Installation Type !! Locations !! Notes<br />
|- <br />
| [https://aws.amazon.com/ Amazon Web Services] || [[Arch Linux AMIs for Amazon Web Services|Custom Images]] || Global ||<br />
|-<br />
| [https://digitalocean.com Digital Ocean] || [https://gitlab.archlinux.org/archlinux/arch-boxes#cloud-image Official Arch cloud image], [https://github.com/gh2o/digitalocean-debian-to-arch Conversion Script] or [https://github.com/robsonde/digitalocean_builder Custom Image] || Global || IPv6 does not work with custom images, but works with conversion script<br />
|-<br />
| [https://cloud.google.com/ Google Cloud Platform] || [https://github.com/GoogleCloudPlatform/compute-archlinux-image-builder Custom Image] || Global || <br />
|-<br />
|}<br />
<br />
== Installation ==<br />
<br />
=== KVM ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[QEMU#Preparing an (Arch) Linux guest]].<br />
<br />
=== OpenVZ ===<br />
<br />
==== Installing the latest Arch Linux on any OpenVZ container provider ====<br />
<br />
{{Warning|Please refer to the warning about the older kernel version and systemd at the top of the page, and note the [[#Preparing the Arch build for use on an OpenVZ 7 container|workaround for OpenVZ 7 below]].}}<br />
<br />
It is possible to directly copy an installation of Arch Linux over the top of a working OpenVZ VPS. This tutorial explains how to create a basic installation of Arch Linux with {{ic|pacstrap}} (as used in a standard install) and then replace the contents of a target VPS with it using [[rsync]].<br />
<br />
This process (with minor modification) also works to migrate existing Arch installations between various environments and has been confirmed to work in migrating from OpenVZ to Xen and from Xen to OpenVZ. For an install to Xen, other hardware-virtualized platforms, or even to physical hardware, extra steps (basically running {{ic|mkinitcpio}} and installing a [[boot loader]]) are needed.<br />
<br />
===== Prerequisites =====<br />
<br />
* A working Arch Linux installation<br />
** To keep things simple, it should match the architecture you want to install on your VPS (x86_64 or i686).<br />
** To build from other distributions, [[Archbootstrap|arch-bootstrap.sh]] can be used in place of {{ic|pacstrap}}.<br />
* The {{Pkg|arch-install-scripts}}, {{Pkg|rsync}}, and {{Pkg|openssh}} packages from the [[official repositories]]<br />
** SSH is not strictly required, but rsync over SSH is the method used here.<br />
* A VPS running any distribution, with {{ic|rsync}} and a working SSH server<br />
** Its architecture (x86_64 or i686) does not matter as long as the OpenVZ installation can support your target architecture.<br />
* OpenVZ's serial console feature (usually accessible via your provider's control panel)<br />
** Without this, any network configuration for the target VPS will have to be done immediately after the "Build" step below.<br />
<br />
===== Building a clean Arch Linux installation =====<br />
<br />
As root, build the installation (optionally replacing {{ic|build}} with your preferred target directory):<br />
<br />
# mkdir build<br />
# pacstrap -cd build<br />
<br />
Other tweaks for the {{ic|pacstrap}} command:<br />
<br />
*{{ic|-C custom-pacman-config.conf}} - Use a custom pacman configuration file. By default, {{ic|pacstrap}} builds according to your local pacman.conf. This determines the architecture (i686 or x86_64) of the build, the mirror list, etc.<br />
*{{ic|-G}} - Prevent {{ic|pacstrap}} from copying your system's pacman keyring to the new build. If you use this option, you will need to run {{ic|pacman-key --init}} and {{ic|pacman-key --populate archlinux}} in the [[#Configuration|Configuration]] step to set up the keyring.<br />
*{{ic|-M}} - Prevent {{ic|pacstrap}} from copying your system's pacman mirror list to the new build.<br />
*You can pass a list of packages to {{ic|pacstrap}} to add them to your install, instead of the default {{ic|base}} group. For example: {{ic|pacstrap -cd build base openssh dnsutils gnu-netcat traceroute vim}}<br />
<br />
====== Preparing the Arch build for use on an OpenVZ 7 container ======<br />
<br />
OpenVZ 7 will fail to start a container if some expected network configuration files do not exist. The easiest way to get around this is as follows:<br />
<br />
# Create the OpenVZ 7 container as Debian 8 (Debian 9 would probably work as well).<br />
# Create the required blank network configuration files inside the Arch build, as follows:<br />
# mkdir build/etc/network<br />
# touch build/etc/network/interfaces<br />
# mkdir -p build/etc/resolvconf/resolv.conf.d<br />
# touch build/etc/resolvconf/resolv.conf.d/base<br />
<br />
===== Replacing everything on the VPS with the Arch build =====<br />
<br />
Replace all files, directories, etc. on your target VPS with the contents of your {{ic|build}} directory (replacing "YOUR.VPS.IP.ADDRESS" below):<br />
<br />
{{Warning|Be careful with the following command. By design, {{ic|rsync}} is very destructive, especially with any of the {{ic|--delete}} options.}}<br />
<br />
# rsync -axH --numeric-ids --delete-delay -e ssh --stats -P build/ YOUR.VPS.IP.ADDRESS:/<br />
<br />
Explanation of options:<br />
<br />
* {{ic|-a}} - Required. Preserves timestamps, permissions, etc.<br />
* {{ic|--delete}} - Required. Deletes anything in the target that does not exist in the source<br />
* {{ic|-x}} - Important. Prevents the crossing of filesystem boundaries (other partitions, /dev, etc.) during the copy<br />
* {{ic|-H}} - Important. Preserves hardlinks<br />
* {{ic|--numeric-ids}} - Important. Does not assign user/group ownership of files based on matching user and group names and instead uses the numeric IDs directly, ensuring proper file ownership on the target system<br />
* {{ic|--delete-delay}} - Recommended. Enables alternate deletion mode which waits to delete anything until the synchronization is otherwise complete, which may reduce the risk of a slow transfer causing the target VPS to lock-up<br />
* {{ic|-e ssh}} - Recommended. Uses {{ic|rsync}} over SSH (recommended for simplicity compared to setting up an {{ic|rsync}} server)<br />
* {{ic|-P}} - Recommended. Shows partial progress information during transfer<br />
* {{ic|--stats}} - Recommended. Shows transfer statistics at the end<br />
<br />
===== Configuration =====<br />
<br />
# Reboot the VPS externally (using your provider's control panel, for example).<br />
# Using OpenVZ's serial console feature, configure the [[network]] and [[Installation_guide#Configure_the_system|basic system settings]] (ignoring fstab generation and arch-chroot steps).<br />
#* If you do not have access to the serial console feature, you will need to preconfigure your network settings before synchronizing Arch to the VPS.<br />
#* On some VPS configuration you will not have a gateway to connect to, here is an example [[netctl]] configuration for this setup. It configures static IP addresses and default routes on venet0 and uses Google Public DNS.<br />
{{hc|/etc/netctl/venet|2=<br />
Description='VPS venet connection'<br />
Interface=venet0<br />
Connection=ethernet<br />
<br />
IP=static<br />
Address=('192.0.2.42/32')<br />
Routes=('default')<br />
<br />
IP6=static<br />
Address6=('2001:db8::1234:5678/128')<br />
Routes6=('default')<br />
<br />
DNS=('2001:4860:4860::8888' '2001:4860:4860::8844' '8.8.8.8' '8.8.4.4')<br />
}}<br />
<br />
=== Xen ===<br />
<br />
{{Expansion|Are there instructions specific to VPSes?}}<br />
See [[Xen]].</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Termite&diff=668193Termite2021-05-07T12:35:35Z<p>Thestinger: Termite is dead and we (the Termite developers) recommend using Alacritty as a replacement</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
[[ja:Termite]]<br />
[[pl:Termite]]<br />
[[pt:Termite]]<br />
{{Note|Termite is no longer actively developed/maintained and [https://github.com/thestinger/termite#termite-is-obsoleted-by-alacritty the developers recommend] using [[Alacritty]] as a replacement. Alacritty has a keyboard text selection mode inspired by Termite and the upcoming 0.8 version has a similar hints mode. Alacritty is dramatically faster than VTE, more robust, more secure and more modern overall.}}<br />
[https://www.github.com/thestinger/termite Termite] is a minimal [https://developer.gnome.org/vte/unstable/ VTE]-based [[:Category:Terminal emulators|terminal emulator]]. It is a ''modal'' application, similar to [[Vim]], with an insert mode and selection mode where keybindings have different functions.<br />
<br />
The configuration file allows changing colors and setting options. Termite supports transparency along with both the 256 color and true color (16 million colors) palettes. It has a similar look and feel to [[urxvt]].<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|termite}} package, or {{AUR|termite-git}} for the development version. For Wayland tiling WM users, you may want to install {{AUR|termite-nocsd}} which disable client side decorations.<br />
<br />
== Usage ==<br />
<br />
Termite starts in insert mode by default. Text may be selected using the mouse, or by using selection-mode keys. In insert mode, {{ic|Ctrl+Shift+c}} is used to copy selected text to the [[X]] clipboard, {{ic|Ctrl+Shift+v}} to paste. {{ic|Ctrl+Tab}} starts scrollback completion, and {{ic|Ctrl+Shift+Up}} / {{ic|Ctrl+Shift+Down}} scroll the screen up or down.<br />
<br />
{{ic|Ctrl+Shift+Space}} enters selection-mode, similar to vim's normal-mode. Many commands are borrowed from [[Vim]], for example {{ic|v}} for visual mode, {{ic|Shift+v}} for visual line mode, {{ic|Ctrl+v}} for visual block mode, {{ic|y}} to copy ("yank") selected text, {{ic|/}} and {{ic|?}} for searching, {{ic|w}}, {{ic|b}}, {{ic|^}}, {{ic|$}} for movement, and {{ic|Escape}} to go back to insert mode.<br />
<br />
== Configuration ==<br />
<br />
Termite looks for configuration files in {{ic|$XDG_CONFIG_HOME/termite/config}}, {{ic|~/.config/termite/config}}, {{ic|$XDG_CONFIG_DIRS/termite/config}} and {{ic|/etc/xdg/termite.cfg}}. The configuration file is used to change options such as font, colors, window hints, etc. The configuration file syntax is inspired by [https://specifications.freedesktop.org/desktop-entry-spec/latest/ XDG Desktop Entry Specification] [[.desktop]] files (inspired by Microsoft Windows ''.ini'' files), with three sections: ''options'', ''colors'', and ''hints''.<br />
<br />
To start customizing termite copy the base example file to your home dir first:<br />
<br />
$ cp /etc/xdg/termite/config ~/.config/termite/config<br />
<br />
=== Font ===<br />
<br />
Fonts are specified in the format {{ic|1=font=<font_name> <font_size>}} under the ''options'' section. {{ic|<font_name>}} is specified according to [[fontconfig]], not [[X Logical Font Description|Xft]]. Use {{ic|fc-list}} to see which fonts are available on the system (see also [[Font configuration#Font paths]]).<br />
<br />
{{hc|~/.config/termite/config|2=<br />
[options]<br />
font = Monospace 9<br />
font = xos4 Terminus 12px<br />
font = Droid Sans Mono 8<br />
}}<br />
<br />
{{Tip|1=You can also specify a {{ic|1=cell_height_scale=<scale>}} property to scale the height of a line (this will not scale the font - it will just add padding above and below a line). According to [https://github.com/thestinger/termite/issues/232#issuecomment-500794994], this property only works for scale values >= 1.}}<br />
<br />
=== Colors ===<br />
<br />
Colors consist of either a 24-bit hex value (e.g. {{ic|#4a32b1}}), or an rgba vector (e.g. {{ic|rgba(16, 32, 64, 0.5)}}). Valid properties for colors are {{ic|foreground}}, {{ic|foreground_bold}}, {{ic|foreground_dim}}, {{ic|background}}, {{ic|cursor}}, {{ic|cursor_foreground}}, and {{ic|colorN}} (where N is an integer from zero through 254; used to assign a 24-bit color value to terminal colorN).<br />
<br />
An amazing collection of termite color schemes can be found here: https://github.com/khamer/base16-termite/tree/master/themes<br />
<br />
{{hc|~/.config/termite/config|2=<br />
[colors]<br />
foreground = #dcdccc<br />
background = #3f3f3f<br />
}}<br />
<br />
=== Reload configuration without exiting ===<br />
<br />
You can reload Termite's config file without exiting by pressing {{ic|Ctrl+Shift+r}} from within Termite.<br />
<br />
Alternatively, you can send a {{ic|USR1}} signal to all Termite instances:<br />
<br />
$ killall -USR1 termite<br />
<br />
== Transparency ==<br />
<br />
As of version 9, Termite supports true transparency via color definitions that specify an alpha channel value [https://github.com/thestinger/termite/issues/191]. This requires a compositor to be running, such as [[picom]] or {{pkg|xcompmgr}}. Most compositors do not require special configuration for Termite to use transparency.<br />
<br />
{{hc|~/.config/termite/config|2=<br />
[colors]<br />
background = rgba(63, 63, 63, 0.8)<br />
}}<br />
<br />
{{Note|In [[i3]], in stacked/tabbed layout, this shows all windows "stacked" on top of each other, in the order they were most recently in the foreground, rather than showing the desktop (the root window) directly behind Termite. This is due to i3 reordering windows rather than hiding invisible windows in tiling mode. You can configure your compositor to make windows with {{ic|1=_NET_WM_STATE=_NET_WM_STATE_HIDDEN}} fully transparent to solve this. For example, for picom use<br />
{{hc|head=~/.config/picom.conf|output=opacity-rule = [<br />
"0:_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'"<br />
];}}<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Ctrl+Shift+t ===<br />
<br />
If opening a new tab through {{ic|Ctrl+Shift+t}} fails with {{ic|no directory uri set}}, [[source]] {{ic|/etc/profile.d/vte.sh}}. See [[GNOME/Tips and tricks#New terminals adopt current directory]].<br />
<br />
If it continues to fail, ensure your [[hostname]] is valid. See {{man|7|hostname}}.<br />
<br />
=== Remote SSH error ===<br />
<br />
When Termite is using remote SSH connection sometimes the error occurs: ''Error opening terminal: xterm-termite.'' or ''Open terminal failed: missing or unsuitable terminal: xterm-termite.''<br />
<br />
This error can occur when trying to edit file with vim or nano. To fix this issue you should execute this command on the remote system:<br />
<br />
$ export TERM=xterm-color<br />
<br />
Alternatively, follow the instructions on Termite's [https://github.com/thestinger/termite#terminfo GitHub]. This will allow you to use all of Termite's features when using SSH, whereas the above may not. [https://github.com/thestinger/termite/issues/229#issuecomment-250659169]<br />
<br />
=== Terminal issues with SSH ===<br />
<br />
When Termite is used for SSH connections to a remote system which does not have its Terminfo, various issues (such as non-working backspace and weird cursor behaviour) could happen. The solution is to send your Terminfo to the remote host.<br />
<br />
On the local host, using Termite:<br />
<br />
$ infocmp > termite.terminfo # export Termite's Terminfo<br />
$ scp termite.terminfo user@remote-host:~/ # or any other method to copy to the remote host<br />
<br />
On the remote host, in the directory where you copied {{ic|termite.terminfo}}:<br />
<br />
$ tic -x termite.terminfo # import Terminfo for current user<br />
$ rm termite.terminfo # optional: remove Terminfo file<br />
<br />
{{Note|After this, you will need to start a new SSH session to have the remote shell load the new Terminfo.}}<br />
<br />
{{Tip|If the remote system is Arch Linux, you can install the {{Pkg|termite-terminfo}} on it instead of exporting, transferring and importing the ''.terminfo'' file manually.}}<br />
<br />
== See also ==<br />
<br />
* [https://github.com/thestinger/termite/blob/master/README.rst Termite readme]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Man_page&diff=660039Man page2021-04-15T15:58:31Z<p>Thestinger: /* man -H */ man-db isn't actually a GNU project: http://man-db.nongnu.org/ and GNU really aren't fans of man pages: https://www.gnu.org/prep/standards/standards.html#Man-Pages</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Command-line]]<br />
[[ar:Man page]]<br />
[[de:Manpages]]<br />
[[es:Man page]]<br />
[[id:Man page]]<br />
[[ja:Man ページ]]<br />
[[ko:Man page]]<br />
[[pt:Man page]]<br />
[[ru:Man page]]<br />
[[zh-hans:Man page]]<br />
{{Related articles start}}<br />
{{Related|Color output in console#man}}<br />
{{Related articles end}}<br />
[[Wikipedia:Man_page|man pages]]—abbreviation for "manual pages"—are the form of documentation that is available on almost all UNIX-like operating systems, including Arch Linux. The command used to display them is {{Ic|man}}.<br />
<br />
In spite of their scope, man pages are designed to be self-contained documents, consequentially limiting themselves to referring to other man pages when discussing related subjects. This is in sharp contrast with the hyperlink-aware [[info manual|Info documents]], GNU's attempt at replacing the traditional man page format.<br />
<br />
== Installation ==<br />
<br />
{{Pkg|man-db}} implements ''man'' on Arch Linux, and [[Core utilities#Essentials|less]] is the default pager used with ''man''. {{Pkg|mandoc}} can also be used.<br />
<br />
{{Pkg|man-pages}} provides the Linux man pages.<br />
<br />
Some localized man pages are also available:<br />
<br />
* {{Pkg|man-pages-cs}} for Czech<br />
* {{Pkg|man-pages-de}} for German<br />
* {{Pkg|man-pages-es}} for Spanish<br />
* {{Pkg|man-pages-fr}} for French<br />
* {{Pkg|man-pages-it}} for Italian<br />
* {{AUR|man-pages-ja}} for Japanese<br />
* {{Pkg|man-pages-nl}} for Dutch<br />
* {{Pkg|man-pages-pl}} for Polish<br />
* {{Pkg|man-pages-pt_br}} for Brazilian Portuguese<br />
* {{Pkg|man-pages-ro}} for Romanian<br />
* {{AUR|man-pages-ru}} for Russian<br />
* {{AUR|man-pages-tr}} for Turkish<br />
* {{Pkg|man-pages-zh_cn}} for Simplified Chinese<br />
* {{Pkg|man-pages-zh_tw}} for Traditional Chinese<br />
<br />
You can use some applications to view man pages:<br />
<br />
* {{App|GNOME Help|Help viewer for [[GNOME]]. It can show man pages via {{ic|yelp man:<name>}} or the undocumented {{ic|Ctrl+L}} keybinding from an existing window.|https://wiki.gnome.org/Apps/Yelp|{{Pkg|yelp}}}}<br />
* {{App|KHelpCenter|Application to show [[KDE]] Applications' documentation. Man pages are in ''UNIX manual pages'' or by running {{ic|khelpcenter man:<name>}}.|https://userbase.kde.org/KHelpCenter|{{Pkg|khelpcenter}}}}<br />
* {{App|[[Wikipedia:Konqueror|Konqueror]]|KDE file manager and web browser. It can show man pages via {{ic|man:<name>}}.|https://konqueror.org/|{{Pkg|konqueror}}}}<br />
* {{App|xman|Provides a categorized look at man pages.|https://xorg.freedesktop.org/|{{pkg|xorg-xman}}}}<br />
<br />
== Accessing man pages ==<br />
<br />
To read a man page, simply enter:<br />
<br />
$ man ''page_name''<br />
<br />
Manuals are sorted into several [[Wikipedia:Man_page#Manual_sections|sections]]. For a full listing see the section entitled "Sections of the manual pages" in {{man|7|man-pages}}.<br />
<br />
Man pages are usually referred to by their name, followed by their section number in parentheses. Often there are multiple man pages of the same name, such as {{man|1|man}} and {{man|7|man}}. In this case, give man the section number followed by the name of the man page, for example:<br />
<br />
$ man 5 passwd<br />
<br />
to read the man page on {{Ic|/etc/passwd}}, rather than the {{Ic|passwd}} utility.<br />
<br />
Or equivalently, the man page followed by the section number, separated by a period:<br />
<br />
$ man passwd.5<br />
<br />
== Searching manuals ==<br />
<br />
Man pages can be searched when the exact name of a page is not known using any of the following equivalent commands:<br />
<br />
$ man -k ''expression''<br />
$ man --apropos ''expression''<br />
$ apropos ''expression''<br />
<br />
{{ic|''expression''}} is interpreted as a regular expression by default.<br />
<br />
To search for keywords in whole page texts, use the {{ic|-K}} option instead.<br />
<br />
{{Note|The search feature is provided by a dedicated cache. By default, maintenance of that cache is handled by {{ic|man-db.service}} which gets periodically triggered by {{ic|man-db.timer}}. If you are getting a "nothing appropriate" message for every search, try manually regenerating the cache by running {{ic|mandb}} as root.}}<br />
<br />
One-line descriptions of man pages can be displayed using the {{ic|whatis}} command. For example, for a brief description of the man page sections about {{ic|ls}}, type:<br />
<br />
{{hc|$ whatis ls|<br />
ls (1p) - list directory contents<br />
ls (1) - list directory contents<br />
}}<br />
<br />
== Page width ==<br />
The man page width is controlled by the {{Ic|MANWIDTH}} environment variable.<br />
<br />
If the number of columns in the terminal is too small (e.g. the window width is narrow), the line breaks will be wrong. This can be very disturbing for reading. You can fix this by setting the MANWIDTH on {{Ic|man}} invocation. With {{Ic|Bash}}, that would be:<br />
<br />
{{Hc|~/.bashrc|<nowiki><br />
man() {<br />
local width=$(tput cols)<br />
[ $width -gt $MANWIDTH ] && width=$MANWIDTH<br />
env MANWIDTH=$width \<br />
man "$@"<br />
}<br />
</nowiki>}}<br />
<br />
== Reading local man pages ==<br />
<br />
Instead of the standard interface, using browsers such as {{Pkg|lynx}} and [[Firefox]] to view man pages allows users to reap info pages' main benefit of hyperlinked text. Alternatives include the following:<br />
<br />
=== Conversion to HTML ===<br />
<br />
==== mandoc ====<br />
<br />
Install the {{Pkg|mandoc}} package. To convert a page, for example {{ic|free(1)}}:<br />
<br />
$ mandoc -Thtml -Ostyle=style.css /usr/share/man/man1/free.1.gz > free.html<br />
<br />
Now open the file called {{ic|free.html}} in your favourite browser.<br />
<br />
==== man2html ====<br />
<br />
First, install {{Pkg|man2html}} from the official repositories.<br />
<br />
Now, convert a man page:<br />
<br />
$ man free | man2html -compress -cgiurl man$section/$title.$section$subsection.html > ~/man/free.html<br />
<br />
Another use for {{Ic|man2html}} is exporting to raw, printer-friendly text:<br />
<br />
$ man free | man2html -bare > ~/free.txt<br />
<br />
==== man -H ====<br />
<br />
The {{pkg|man-db}} implementation also has the ability to do this on its own:<br />
<br />
$ man -H free<br />
<br />
This will read your {{ic|BROWSER}} [[environment variable]] to determine the browser. You can override this by passing the binary to the {{ic|-H}} option.<br />
<br />
==== roffit ====<br />
<br />
First install {{AUR|roffit}} from [[AUR]].<br />
<br />
To convert a man page:<br />
<br />
$ gunzip -c /usr/share/man/man1/free.1.gz | roffit > free.html<br />
<br />
=== Conversion to PDF ===<br />
<br />
man pages have always been printable: they are written in troff, which is fundamentally a typesetting language. If you have {{Pkg|ghostscript}} installed, you can convert a man page to PDF using {{ic|man -t <manpage> {{!}} ps2pdf - <pdf>}}.<br />
<br />
Caveats: Fonts are generally limited to Times at hardcoded sizes. There are no hyperlinks. Some man pages were specifically designed for terminal viewing, and will not look right in PS or PDF form.<br />
<br />
== Online man pages ==<br />
<br />
There are several online databases of man pages, including:<br />
<br />
* [https://man.archlinux.org Arch manual pages]—contains man pages from Arch Linux packages. Used for [[Template:man|man page links]] from the wiki. You can also use the {{ic|!archman}} DuckDuckGo [https://duckduckgo.com/bang bang] to search through the Arch manual pages directly.<br />
* [http://man7.org/linux/man-pages/index.html man7.org]—The Linux man-pages project. Upstream of the {{pkg|man-pages}} package.<br />
* [https://manned.org/ manned.org]—collection from various Linux distributions, BSD, etc., with multiple package versions<br />
* [https://linux.die.net/man/ linux.die.net]<br />
* [https://man.cx/ man.cx]<br />
* [https://manpages.debian.org/ Debian man pages]<br />
* [http://manpages.ubuntu.com/ Ubuntu man pages]<br />
* [https://leaf.dragonflybsd.org/cgi/web-man DragonFlyBSD man pages]<br />
* [https://www.freebsd.org/cgi/man.cgi FreeBSD man pages]<br />
* [https://man.netbsd.org/ NetBSD man pages]<br />
* [https://man.openbsd.org OpenBSD man pages]<br />
* [http://man.cat-v.org/plan_9/ Plan 9 Manual — Volume 1]<br />
* [http://man.cat-v.org/inferno/ Inferno Manual — Volume 1]<br />
* [https://www.unix.com/man-page-repository.php The UNIX and Linux forums man page repository]<br />
<br />
There is also a [https://gist.github.com/rixx/6cb5fa38f694009ad0bd50c275bb61f2 comparison table].<br />
<br />
{{Warning|Some distributions provide patched or outdated man pages that differ from those provided by Arch. Exercise caution when using online man pages.}}<br />
<br />
==Noteworthy man pages==<br />
<br />
Here follows a non-exhaustive list of noteworthy pages that might help you understand a lot of things more in-depth. Some of them might serve as a good reference (like the ASCII table).<br />
<br />
* {{man|7|ascii}}<br />
* {{man|7|boot}}<br />
* {{man|7|charsets}}<br />
* {{man|1|chmod}}<br />
* {{man|7|credentials}}<br />
* {{man|5|fstab}}<br />
* {{man|7|hier}}<br />
* {{man|1|systemd}}<br />
* {{man|1p|locale}}, {{man|5|locale}}, {{man|7|locale}}<br />
* {{man|3|printf}}<br />
* {{man|5|proc}}<br />
* {{man|7|regex}}<br />
* {{man|7|signal}}<br />
* {{man|5|term}}, {{man|7|term}}<br />
* {{man|5|termcap}}<br />
* {{man|5|terminfo}}<br />
* {{man|7|utf-8}}<br />
<br />
More generally, have a look at [http://man7.org/linux/man-pages/dir_section_7.html category 7 (miscellaneous) pages]:<br />
<br />
$ man -s 7 -k ".*" <br />
<br />
Arch Linux specific pages:<br />
<br />
* {{man|5|alpm-hooks}}<br />
* {{man|3|libalpm}}<br />
* {{man|8|makepkg}}<br />
* {{man|5|makepkg.conf}}<br />
* {{man|1|makepkg-template}}<br />
* {{man|8|mkinitcpio}}<br />
* {{man|8|pacman}}<br />
* {{man|5|pacman.conf}}<br />
* {{man|8|pacman-conf}}<br />
* {{man|8|pacman-key}}<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gentoo.org/wiki/Man_page man page - Gentoo wiki article]<br />
* [https://linuxtidbits.wordpress.com/2013/08/21/wtfm-write-the-fine-manual-with-pod2man-text-converter/ Write The Fine Manual with pod2man]<br />
* [https://manpages.bsd.lv/history.html History of UNIX Manpages]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=576019Security2019-06-19T22:10:43Z<p>Thestinger: /* Memory */ it's not more complex than glibc malloc (compare the code) and it's more efficient in terms of lower memory usage for metadata and substantially lower fragmentation so clarify that part + remove redundant Firejail promotion</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{AUR|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords], [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password. Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the {{man|8|pam_cracklib}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== Memory ==<br />
<br />
=== Hardened Malloc ===<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened-malloc-git}}) is a hardened replacement for glibc's malloc(). The project was originally developed for integration into Android's Bionic and musl by Daniel Micay, of GrapheneOS, but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in /etc/ld.so.preload. For example, man fails to work properly unless its seccomp environment flag is disabled due to not having {{ic|getrandom}} in the standard whitelist, although this can be easily fixed by rebuilding it with the system call added. Since hardened_malloc has a performance cost, you may want to decide which implementation to use on a case-by-case basis based on attack surface and performance needs.<br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
{{bc|1=LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox}}<br />
<br />
Proper usage with [[Firejail]] can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]* and [[Steam]].<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
<br />
To lockout a user for ten minutes {{ic|1=unlock_time=600}} after three failed login attempts {{ic|1=deny=3}}, add the parameters to the PAM configuration as follows:<br />
<br />
{{hc|/etc/pam.d/system-login|2=auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog<br />
}}<br />
<br />
That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally2 --reset --user ''username''<br />
<br />
{{ic|unlock_time}} is specified in seconds. If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user is then unable to login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] is commonly [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] because of its architecture and dated design. Thus it is recommended to avoid running it as root.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run it without root privileges.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There's a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Sudo, an alternative|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo --edit filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
$ export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical_(company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be set to {{ic|0}} for a maximum level of security.<br />
<br />
BPF/Seccomp compilation can be useful in specific domains, such as dynamic servers (e.g. orchestration platforms like Mesos and Kubernetes). It is not usually useful for desktop users or for static servers. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference. The [[Wikipedia:Spectre (security vulnerability)|Spectre]] attacks, published early 2018, are prominent respective exploits.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|wireguard-arch}} cannot be loaded. Restricting loading kernel modules can be done by adding {{ic|1=module.sig_enforce=1}} to the kernel command line, further documentation can be found [https://www.kernel.org/doc/html/v5.2-rc3/admin-guide/module-signing.html here].<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (v4.14.5 or later), {{Pkg|linux-lts}} (v4.14.15 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications. Unprivileged usage is disabled by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general info.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of service, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
=== DNS ===<br />
<br />
{{Accuracy|Your browser might notice DNS spoofing with [[HSTS]].}}<br />
<br />
[[DNS]] queries are, by default on most systems, sent and received unencrypted and without checking for authentication of receipt from qualified servers. This could then allow [[Wikipedia:Man-in-the-middle_attack|man-in-the-middle attacks]], whereby an attacker intercepts your DNS queries and modifies the responses to deliver you an IP address leading to a [[Wikipedia:Phishing|phishing]] page to collect your valuable information. Neither you nor the browser/other software would be aware since the DNS protocol takes the legitimacy of query results for granted.<br />
<br />
[[DNSSEC]] is a set of standards in place that requires DNS servers to provide clients with origin authentication of DNS data, authenticated denial of existence, and data integrity. It, however, is not yet widely used. With DNSSEC enabled, an attacker can not make modifications to your DNS queries and the returning results, but would still be able to read them.<br />
<br />
[[DNSCrypt]], as well as later alternative protocol developments ''DNS over TLS'' and ''DNS over HTTPS'', use cryptography to secure communications with DNS servers. Usually only one protocol is employed on a system level. See [[Domain name resolution#DNS servers]] for supporting software.<br />
<br />
If you have a domain name, set a [[Sender Policy Framework]] policy to combat email spoofing.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
{{Merge|Transport Layer Security|There's a dedicated article.}}<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy:<br />
<br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow vulnerability alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch Security Team]].<br />
<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Disk encryption|full disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header|detached encryption headers]] placed on the boot partition. <br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://srlabs.de/badusb BadUSB], [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
== Rebuilding packages ==<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=576018Security2019-06-19T22:06:38Z<p>Thestinger: /* Hardened Malloc */ Xorg does works fine per another user report and the reason man doesn't work is known</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{AUR|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords], [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password. Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the {{man|8|pam_cracklib}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== Memory ==<br />
<br />
=== Hardened Malloc ===<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened-malloc-git}}) is a hardened replacement for glibc's malloc(). The project was originally developed for integration into Android's Bionic and musl by Daniel Micay, of GrapheneOS, but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in /etc/ld.so.preload. For example, man fails to work properly unless its seccomp environment flag is disabled due to not having {{ic|getrandom}} in the standard whitelist, although this can be easily fixed by rebuilding it with the system call added. Between these, and because hardened_malloc is arguably less efficient and more complex than the standard malloc, it is suggested that one use it for more at risk applications, such as those that face the internet. It can also be used as a complement to sandboxed applications inside [[Firejail]]. <br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
{{bc|1=LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox}}<br />
<br />
Proper usage with Firejail can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]* and [[Steam]].<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
<br />
To lockout a user for ten minutes {{ic|1=unlock_time=600}} after three failed login attempts {{ic|1=deny=3}}, add the parameters to the PAM configuration as follows:<br />
<br />
{{hc|/etc/pam.d/system-login|2=auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog<br />
}}<br />
<br />
That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally2 --reset --user ''username''<br />
<br />
{{ic|unlock_time}} is specified in seconds. If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user is then unable to login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] is commonly [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] because of its architecture and dated design. Thus it is recommended to avoid running it as root.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run it without root privileges.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There's a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Sudo, an alternative|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo --edit filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
$ export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical_(company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be set to {{ic|0}} for a maximum level of security.<br />
<br />
BPF/Seccomp compilation can be useful in specific domains, such as dynamic servers (e.g. orchestration platforms like Mesos and Kubernetes). It is not usually useful for desktop users or for static servers. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference. The [[Wikipedia:Spectre (security vulnerability)|Spectre]] attacks, published early 2018, are prominent respective exploits.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|wireguard-arch}} cannot be loaded. Restricting loading kernel modules can be done by adding {{ic|1=module.sig_enforce=1}} to the kernel command line, further documentation can be found [https://www.kernel.org/doc/html/v5.2-rc3/admin-guide/module-signing.html here].<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (v4.14.5 or later), {{Pkg|linux-lts}} (v4.14.15 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications. Unprivileged usage is disabled by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general info.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of service, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
=== DNS ===<br />
<br />
{{Accuracy|Your browser might notice DNS spoofing with [[HSTS]].}}<br />
<br />
[[DNS]] queries are, by default on most systems, sent and received unencrypted and without checking for authentication of receipt from qualified servers. This could then allow [[Wikipedia:Man-in-the-middle_attack|man-in-the-middle attacks]], whereby an attacker intercepts your DNS queries and modifies the responses to deliver you an IP address leading to a [[Wikipedia:Phishing|phishing]] page to collect your valuable information. Neither you nor the browser/other software would be aware since the DNS protocol takes the legitimacy of query results for granted.<br />
<br />
[[DNSSEC]] is a set of standards in place that requires DNS servers to provide clients with origin authentication of DNS data, authenticated denial of existence, and data integrity. It, however, is not yet widely used. With DNSSEC enabled, an attacker can not make modifications to your DNS queries and the returning results, but would still be able to read them.<br />
<br />
[[DNSCrypt]], as well as later alternative protocol developments ''DNS over TLS'' and ''DNS over HTTPS'', use cryptography to secure communications with DNS servers. Usually only one protocol is employed on a system level. See [[Domain name resolution#DNS servers]] for supporting software.<br />
<br />
If you have a domain name, set a [[Sender Policy Framework]] policy to combat email spoofing.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
{{Merge|Transport Layer Security|There's a dedicated article.}}<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy:<br />
<br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow vulnerability alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch Security Team]].<br />
<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Disk encryption|full disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header|detached encryption headers]] placed on the boot partition. <br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://srlabs.de/badusb BadUSB], [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
== Rebuilding packages ==<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=576017Security2019-06-19T22:03:56Z<p>Thestinger: /* Hardened Malloc */ build options, not environment variables (there's no runtime configuration)</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{AUR|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords], [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password. Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the {{man|8|pam_cracklib}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== Memory ==<br />
<br />
=== Hardened Malloc ===<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened-malloc-git}}) is a hardened replacement for glibc's malloc(). The project was originally developed for integration into Android's Bionic and musl by Daniel Micay, of GrapheneOS, but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in /etc/ld.so.preload - Xorg fails to start, and man fails to work properly unless its seccomp environment flag is disabled. Between these, and because hardened_malloc is arguably less efficient and more complex than the standard malloc, it is suggested that one use it for more at risk applications, such as those that face the internet. It can also be used as a complement to sandboxed applications inside [[Firejail]]. <br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
{{bc|1=LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox}}<br />
<br />
Proper usage with Firejail can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]* and [[Steam]].<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
<br />
To lockout a user for ten minutes {{ic|1=unlock_time=600}} after three failed login attempts {{ic|1=deny=3}}, add the parameters to the PAM configuration as follows:<br />
<br />
{{hc|/etc/pam.d/system-login|2=auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog<br />
}}<br />
<br />
That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally2 --reset --user ''username''<br />
<br />
{{ic|unlock_time}} is specified in seconds. If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user is then unable to login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] is commonly [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] because of its architecture and dated design. Thus it is recommended to avoid running it as root.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run it without root privileges.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There's a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Sudo, an alternative|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo --edit filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
$ export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical_(company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be set to {{ic|0}} for a maximum level of security.<br />
<br />
BPF/Seccomp compilation can be useful in specific domains, such as dynamic servers (e.g. orchestration platforms like Mesos and Kubernetes). It is not usually useful for desktop users or for static servers. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference. The [[Wikipedia:Spectre (security vulnerability)|Spectre]] attacks, published early 2018, are prominent respective exploits.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|wireguard-arch}} cannot be loaded. Restricting loading kernel modules can be done by adding {{ic|1=module.sig_enforce=1}} to the kernel command line, further documentation can be found [https://www.kernel.org/doc/html/v5.2-rc3/admin-guide/module-signing.html here].<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (v4.14.5 or later), {{Pkg|linux-lts}} (v4.14.15 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications. Unprivileged usage is disabled by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general info.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of service, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
=== DNS ===<br />
<br />
{{Accuracy|Your browser might notice DNS spoofing with [[HSTS]].}}<br />
<br />
[[DNS]] queries are, by default on most systems, sent and received unencrypted and without checking for authentication of receipt from qualified servers. This could then allow [[Wikipedia:Man-in-the-middle_attack|man-in-the-middle attacks]], whereby an attacker intercepts your DNS queries and modifies the responses to deliver you an IP address leading to a [[Wikipedia:Phishing|phishing]] page to collect your valuable information. Neither you nor the browser/other software would be aware since the DNS protocol takes the legitimacy of query results for granted.<br />
<br />
[[DNSSEC]] is a set of standards in place that requires DNS servers to provide clients with origin authentication of DNS data, authenticated denial of existence, and data integrity. It, however, is not yet widely used. With DNSSEC enabled, an attacker can not make modifications to your DNS queries and the returning results, but would still be able to read them.<br />
<br />
[[DNSCrypt]], as well as later alternative protocol developments ''DNS over TLS'' and ''DNS over HTTPS'', use cryptography to secure communications with DNS servers. Usually only one protocol is employed on a system level. See [[Domain name resolution#DNS servers]] for supporting software.<br />
<br />
If you have a domain name, set a [[Sender Policy Framework]] policy to combat email spoofing.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
{{Merge|Transport Layer Security|There's a dedicated article.}}<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy:<br />
<br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow vulnerability alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch Security Team]].<br />
<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Disk encryption|full disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header|detached encryption headers]] placed on the boot partition. <br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://srlabs.de/badusb BadUSB], [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
== Rebuilding packages ==<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Classroom&diff=511942Classroom2018-02-25T05:42:39Z<p>Thestinger: /* Requested classes */ grsecurity is no longer publicly available and it's not widely privately available so there's little hope of classes about it</p>
<hr />
<div>[[Category:Classroom]]<br />
[https://bbs.archlinux.org/viewtopic.php?id=143671 Arch Classroom] is a project to host classes for people to learn new skills and knowledge on various technical topics. The classes are taught by volunteers from the Arch Linux community. Classes are held on IRC and anyone is welcome to attend regardless of their level of expertise.<br />
<br />
== Classes ==<br />
<br />
Classes are held in the IRC channel '''#archlinux-classroom''' on the [http://www.freenode.net/ Freenode] network.<br />
<br />
=== Upcoming classes ===<br />
<br />
Classes are announced on the mailing list arch-general, the forums, and other broadcasting places like twitter. The following table lists classes being developed and classes announced. The stages for class development are drafting, scheduling, and canceled. Once a class has been announced, the date and time are given.<br />
<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Stage / Date'''<br />
| align="center" style="background:#f0f0f0;"|'''Class Title'''<br />
| align="center" style="background:#f0f0f0;"|'''Instructor(s)'''<br />
| align="center" style="background:#f0f0f0;"|'''Announcements and Notes'''<br />
|-<br />
| 2017-10-27 07:00 UTC<br />
| ''Python for Beginners''<br />
| pulec<br />
| https://github.com/archclassroom/python-beginners<br />
|- style="background:#e4e4e4"<br />
| drafting<br />
| ''C Programming''<br />
| HalosGhost<br />
| https://ptpb.pw/r/~alcclass<br />
|}<br />
<br />
=== Previous classes ===<br />
<br />
Classes that have already happened. (Maybe students and teachers could write up some info on the experience, similar to the arch con pages.)<br />
<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Date'''<br />
| align="center" style="background:#f0f0f0;"|'''Class Title'''<br />
| align="center" style="background:#f0f0f0;"|'''Instructor(s)'''<br />
| align="center" style="background:#f0f0f0;"|'''Logs'''<br />
|- style="background:#e4e4e4"<br />
| 2017-06-04<br />
| ''The Beginner's Guide to Arch Linux Package Management''<br />
| Eschwartz<br />
| [https://archwomen.org/media/project_classroom/classlogs/2017-06-04-the_beginners_guide_to_arch_linux_package_management.txt 17:00 UTC]<br />
|-<br />
| 2016-12-11<br />
| ''Getting started with Arch Linux packaging''<br />
| HalosGhost and meskarune<br />
| [https://archwomen.org/media/project_classroom/classlogs/2016-12-11-getting_started_with_arch_linux_packaging.txt 19:00 UTC]<br />
|- style="background:#e4e4e4"<br />
| 2016-07-16<br />
| ''Git for Gits''<br />
| polyzen and meskarune<br />
| [https://archwomen.org/media/project_classroom/classlogs/2016-07-16-git_for_gits.txt 16:00 UTC]<br />
|-<br />
| 2015-05-17<br />
| ''An Imperfect Introduction to Static Typing''<br />
| HalosGhost<br />
| [https://archwomen.org/media/project_classroom/classlogs/2015-05-17-an_imperfect_introduction_to_static_typing.txt 23:00 UTC]<br />
|- style="background:#e4e4e4"<br />
| 2014-09-05<br />
| ''Introduction to Scheme and Functional Programming''<br />
| nisstyre<br />
| [https://archwomen.org/media/project_classroom/classlogs/2014-09-05-introduction_to_scheme_and_functional_programming.txt 20:00 UTC]<br />
|-<br />
| 2014-05-31<br />
| ''A First Look at the Linux Kernel''<br />
| jy2wong<br />
| [https://archwomen.org/media/project_classroom/classlogs/2014-05-31-a_first_look_at_the_linux_kernel.txt 16:00 UTC]<br />
|- style="background:#e4e4e4"<br />
| 2014-04-19<br />
| ''PKGBUILD Class''<br />
| CalimeroTeknik<br />
| [https://archwomen.org/media/project_classroom/classlogs/2014-04-19-pkgbuilds_09%3a30-UTC.txt 9:30 UTC] and [https://archwomen.org/media/project_classroom/classlogs/2014-04-19-pkgbuilds_16%3a00-UTC.txt 16:00 UTC]<br />
|-<br />
| 2013-09-14<br />
| ''Beginners Guide to Package Maintaining''<br />
| gtmanfred and KaiSforza<br />
| [https://archwomen.org/media/project_classroom/classlogs/2013-09-14-beginner_pkgbuilds1.txt 16:45 UTC]<br />
|}<br />
<br />
=== Requested classes ===<br />
<br />
If you are interested in taking a class on a particular topic, list it below.<br />
<br />
* programming: bash scripting basics, AWK/GAWK, C++, Python, Ruby, Rust, Java 8, Haskell, makefiles or other build systems, debugging<br />
* VCS: Git basics, Mercurial, Darcs, Subversion, introduction VCS and general concepts<br />
* security: using GPG (basic concepts, etc.), how to configure SELinux/AppArmor/TOMOYO, managing SSH keys<br />
* shell: prompt creation, zsh or bash configuration, zsh or bash completions<br />
* Pacman - An Introduction<br />
* Using [[ABS]] - For new users of Arch.<br />
* Finding an answer / creating a bug report - How and where to search when you have a problem.<br />
* Creating backups - Different methods of creating backups of your files.<br />
* History of Linux and F/LOSS<br />
* understanding makepkg, understanding [[AUR helpers]]<br />
<br />
== Teaching ==<br />
<br />
If you want to teach a class, the first thing you need is a topic. There is no limit other than it should be interesting to Arch Linux users and that it can be presented over IRC. See the list of requested classes on this page for ideas. You can also teach the same topic as one of the previous classes.<br />
<br />
If you are interested in teaching, contact one of the [https://archwomen.org/wiki/projects:classroom:admin#coordinators coordinators], or [[User:Meskarune]] who will guide you in creating a class. The following sections outline the process. Also see the [https://archwomen.org/wiki/projects:classroom:start administration page] on the Arch Women wiki.<br />
<br />
=== Create content ===<br />
<br />
The class requires a lesson plan which at a minimum outlines the topics the class covers. It will serve as your notes and guide you through your class. Give it as much detail as you like. It will later be published to help students who missed the class as well as future instructors.<br />
<br />
Start your lesson plan with a goal or objective in mind. What will students be expected to learn in this class? Decide what sort of students you are targeting — beginning Linux users, people familiar with particular software, and so on. (Many past classes targeted both beginners and advanced users.) Make a list with all the software requirements the class will need, and a list of prerequisites with the knowledge students should have before taking the class.<br />
<br />
Create additional materials to aid the students. Diagrams and code listings can help students visualize the concepts taught. Essays can further delve into details not covered in a class and also help students who have difficulty following the tumultuous IRC format. You may also want to create a reading list of outside sources.<br />
<br />
Plan for the class to run for 1-1.5 hours. Expect the students to interrupt with comments and questions. If the subject can not be reasonably covered in that time, the class can be broken into segments, e.g. part one today and part two in a week.<br />
<br />
All materials and lesson plans are hosted in the [https://github.com/archwomen/classroom-media classroom-media] git repository and made available on the website of Arch Women.<br />
<br />
=== Scheduling ===<br />
<br />
Decide on a date and time (UTC) which best works for you. Since Arch Linux has a global reach, hold multiple sessions to accommodate the different timezones. Perhaps one session in the morning for Asia and Oceania and another in the evening for Europe, Africa, and the Americas.<br />
<br />
Classes are scheduled a month beforehand to give time to make announcements.<br />
<br />
=== Announcing the class ===<br />
<br />
Announcements are made on the arch-general mailing list, the Arch Linux forums and Arch Women's twitter a few weeks before the class is held.<br />
<br />
The following information is required:<br />
* title and description of the class<br />
* prerequisites (if any)<br />
* date and time<br />
* biography of instructor(s)<br />
<br />
== See also ==<br />
<br />
* [https://wiki.ubuntu.com/Classroom Ubuntu Classroom]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=143671 Arch Linux forum discussion]<br />
* [https://archwomen.org/wiki/projects:classroom:start Administration page on Arch Women wiki]<br />
* [https://github.com/archwomen/classroom-media Teaching materials git repository]<br />
* [https://github.com/open-source-society/computer-science#introduction-to-computer-science Open Source Society University]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Roll_Call&diff=511941DeveloperWiki:Roll Call2018-02-25T05:41:39Z<p>Thestinger: remove self (retired)</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
==Developers==<br />
<br />
* Aaron Griffin<br />
* Allan McRae<br />
** Packaging (toolchain)<br />
** Pacman development<br />
* Anatol Pomozov<br />
** Packaging for Ruby language, cross-compilers, ...<br />
** Bug tracking for many packages (including working with upstream)<br />
** Supporting users at forum<br />
* Andreas Radke<br />
** Packaging (Bluetooth, Printing, Xorg, LibreOffice, LTS kernel)<br />
* Andrew Gregory<br />
** Pacman development<br />
* Ángel Velásquez<br />
** Inactive<br />
** Packaging (python, wicd, subversion) -fairly inactive, felix have done most of the workload since he joined-<br />
** i18n for Spanish (pacman, aur)<br />
** archweb: design rebuild (was working on a bootstrapped website years ago, then bootstrap 3 was released, didn't completed the rewrite and make the patches, could do that soon with bootstrap 4 RC)<br />
* Antonio Rojas<br />
** Packaging (KDE, math stuff, orphans)<br />
* Bartłomiej Piotrowski<br />
** Packaging (mostly core and extra)<br />
** Bug tracker admin<br />
** Planet admin<br />
** Helping with rebuilds<br />
* Dan McGee<br />
** Packaging<br />
** Archweb (but fairly inactive on this front)<br />
* Dave Reisner<br />
** Packaging<br />
* Eric Bélanger<br />
* Evangelos Foutras<br />
** Packaging (Xfce, LLVM/Clang)<br />
** Rebuild automation (arch-rebuilds)<br />
** Might be inactive for some period in 2016 and/or 2017<br />
* Felix Yan<br />
** Packaging (Python, Perl, Haskell, Nodejs, KDE/Qt, Deepin, Chinese/Japanese l10n, and more)<br />
* Florian Pritz<br />
** Packaging<br />
** Serveradmin<br />
** Mirrors<br />
** Mailinglists<br />
* Gaetan Bisson<br />
** Packaging<br />
* Gerardo Pozzi<br />
** Maintaining: ArchISO<br />
* Giovanni Scafora<br />
* Guillaume Alaux<br />
** Packaging ([extra] and [Community] – mainly Java related packages)<br />
* Ionuț Mircea Bîru<br />
** Currently I'm in charge of paying all our servers and signing.<br />
** I don't do any packaging this days, unless there is a bug in a package that affects or annoys me.<br />
** Group contact for archlinux on freenode.<br />
* Jan de Groot<br />
** Packaging (GNOME). Not very active ATM.<br />
* Jan Steffens<br />
** Packaging (GNOME, misc other stuff)<br />
* Jürgen Hötzel<br />
** Packaging <br />
*** OCaml <br />
*** Various lisp programming languages<br />
*** Emacs<br />
* Laurent Carlier<br />
** Packaging (mesa, xorg)<br />
* Lukas Fleischer<br />
** Packaging<br />
** aurweb development<br />
** projects.archlinux.org maintenance<br />
* Maxime Gauduin<br />
** Packaging (LightDM, FFmpeg and encoding related stuff)<br />
* Pierre Schmitz<br />
** Packaging<br />
*** PHP<br />
*** See https://www.archlinux.org/packages/?maintainer=pierre<br />
** Maintaining<br />
*** install ISO and bootstrap packages<br />
*** Keyring<br />
*** wiki and bbs software (MediaWiki, FluxBB, custom themes and extensions)<br />
* Ray Rashif<br />
** Packaging (Audio, misc productivity and creativity, others)<br />
** Sporadic inactivity (mostly due to hardware issues needing to work in Windowz with pain)<br />
* Rémy Oudompheng<br />
** Packaging (TeXLive)<br />
* Ronald van Haren<br />
** Packaging (misc, scientific applications, enlightenment)<br />
* Sébastien Luttringer<br />
** Packaging: https://www.archlinux.org/packages/?maintainer=seblu<br />
** Interested in:<br />
*** devtools maintainership<br />
*** archive project<br />
*** infra team<br />
* Sven-Hendrik Haase<br />
** Packaging (NVIDIA stuff, multimedia stuff)<br />
* Thomas Bächler<br />
** Key signing<br />
** <strike>Packaging</strike> inactive<br />
* Thomas Dziedzic<br />
* Tobias Powalowski<br />
** Packaging (Kernel, Hardware support, Filesystems support, Boot process, Base components)<br />
** Maintaining Archboot installer ISO<br />
* Tom Gundersen<br />
<br />
== Trusted Users ==<br />
<br />
* Alad Wenter<br />
** Packaging<br />
** Wiki administration<br />
** IRC op (#archlinux, #archlinux-offtopic, #archlinux-aur, #archlinux-wiki, others)<br />
* Alexander Rødseth<br />
* Alexandre Filgueira<br />
* Anatol Pomozov<br />
* Andrew Crerar<br />
** Packaging<br />
** AUR Requests<br />
* Andrzej Giniewicz<br />
* Antonio Rojas<br />
* Balló György<br />
** Packaging (Cinnamon, GNOME Flashback, LXDE)<br />
* Baptiste Jonglez<br />
* Bruno Pagani<br />
* Christian Hesse<br />
* Christian Rebischke<br />
** Security team<br />
* David Runge<br />
** Packaging (mainly pro-audio)<br />
* Evgeniy Alekseev<br />
** Packaging (mostly scientific packages and Qt applications)<br />
** AUR requests<br />
* Fabio Castelli<br />
** Packaging<br />
* Giancarlo Razzolini<br />
* Ike Devolder<br />
** Packaging<br />
* Jakob Gruber<br />
** Packaging<br />
* Jaroslav Lichtblau<br />
** Packaging<br />
** AUR requests<br />
* Jelle van der Waa<br />
** Packaging (Random Python modules, XMonad/XMobar and Haskell related packages)<br />
** IRC Op #archlinux, #archlinux-offtopic, (TU channel OP too)<br />
* Jerome Leclanche<br />
** Packaging (LXQt)<br />
* Jiachen Yang<br />
** Packaging (cutegram, libqtelegram-ae, telegramqml, lsw)<br />
* Johannes Löthberg<br />
** Packaging<br />
** AUR requests<br />
* Jonathan Steel<br />
** Packaging<br />
* Kyle Keen<br />
* Laurent Carlier<br />
** Packaging<br />
* Levente Polyak<br />
** Packaging<br />
** Security team<br />
** Reproducible builds<br />
* Lukas Fleischer<br />
** Packaging<br />
** aurweb development<br />
** projects.archlinux.org maintenance<br />
* Lukas Jirkovsky<br />
** Packaging<br />
* Massimiliano Torromeo<br />
** Packaging<br />
* Maxime Gauduin<br />
** Packaging (Pantheon, emulators, music players and stuff)<br />
* NicoHood<br />
* Nicola Squartini<br />
* Pierre Neidhardt<br />
** Packaging<br />
* Sébastien Luttringer<br />
** Packaging: https://www.archlinux.org/packages/?maintainer=seblu<br />
* Sergej Pupykin<br />
* speps<br />
** Packaging (mostly Audio stuff)<br />
* Thomas Dziedzic<br />
* Thorsten Töpper<br />
** Packaging<br />
* Timothy Redaelli<br />
* Xyne<br />
** Packaging<br />
** Forum Moderation<br />
<br />
==Support Staff==<br />
<br />
* Dario Giovannetti<br />
** Wiki administration<br />
* Doug Newgard<br />
** Bug tracker basic triage, sorting, correction, and assigning<br />
* Eric Waller<br />
** Forum Administration and Moderation<br />
* Jakob Wadsager<br />
* Jason Ryan<br />
** Forum Administration and Moderation<br />
** Wiki Administration<br />
* Jesse McClure (Trilby)<br />
** Forum moderation<br />
* Jordan Beaver<br />
** IRC op<br />
* Levente Polyak<br />
** See above (TU)<br />
* Phillip Smith (fukawi2)<br />
** Forum Moderation<br />
* Remi Gacogne<br />
** Security team<br />
** Reproducible builds<br />
* tigrmesh<br />
* WorMzy Tykashi<br />
** Forum moderation<br />
* Xyne<br />
** Packaging<br />
** Forum Moderation</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Package_Maintainers&diff=497278Package Maintainers2017-11-18T18:06:01Z<p>Thestinger: /* Some Past Trusted Users */ drop email for self</p>
<hr />
<div>[[Category:Arch development]]<br />
[[fr:TU]]<br />
[[ja:Trusted Users]]<br />
[[pt:Trusted Users]]<br />
The [https://www.archlinux.org/people/trusted-users/ Trusted Users] serve the following purposes:<br />
# Maintain the ''community'' repository as an intermediary between Arch Linux's [[official repositories]] and the unsupported package collection in the [[AUR]].<br />
# Maintain, manage, and watch over the operation of the [[AUR]].<br />
<br />
== How do I become a TU? ==<br />
The ''minimum'' requirements to becoming a TU are as follows:<br />
* know basic shell scripting<br />
* maintain a few packages in AUR with clean, high-quality PKGBUILDs<br />
* basic community involvement (mailing list, forums, IRC)<br />
* know Google-Fu<br />
* a general idea of the kind of packages you want to maintain (basically, why do you want to become TU?)<br />
<br />
<br />
Even though you could become a TU by merely fulfilling those minimum requirements, the people judging you [https://aur.archlinux.org/trusted-user/TUbylaws.html#_standard_voting_procedure during voting] might expect more of you. Such as:<br />
* involvement in the bug tracker (reporting, research, info)<br />
* patches for Arch projects<br />
* involvement in a few open-source projects (even if they are your own)<br />
<br />
<br />
In case you still feel up to becoming a TU after reading these lists, you should find another TU to sponsor you and write a witty application signed with your GPG key to the aur-general mailing list.<br />
<br />
{{Note|Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU.}}<br />
<br />
For more information, please see [https://aur.archlinux.org/trusted-user/TUbylaws.html Trusted User Bylaws] and [[AUR Trusted User Guidelines]].<br />
<br />
== Active Trusted Users ==<br />
{| class="wikitable"<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|style="font-weight: bold;"|E-Mail<br />
|-<br />
|[https://aur.archlinux.org/packages/?K=Alad&SeB=m alad]||[[User:Alad|Alad Wenter]]||nynq ng znvyobk qbg bet (rot13)<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=alucryd&SeB=m alucryd]||Maxime Gauduin||alucryd@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ambrevar&SeB=m Ambrevar]||[[User:Ambrevar|Pierre Neidhardt]]||ambrevar@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anatolik&SeB=m anatolik]||Anatol Pomozov||anatol dot pomozov + arch at gmail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anthraxx&SeB=m anthraxx]||[[User:anthraxx|Levente Polyak]]||anthraxx [at] archlinux [dot] org<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=arcanis arcanis]||Evgeniy Alekseev||arcanis DOT arch AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ArchangeGabriel&SeB=m ArchangeGabriel]||Bruno Pagani||bruno.n.pagani@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=arojas arojas]||Antonio Rojas||arojas@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Atsutane&SeB=m Atsutane]||Thorsten Töpper||atsutane {0x40} freethoughts {0x2E} de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Barthalion&SeB=m Barthalion]||Bartłomiej Piotrowski||spam@bpiotrowski.pl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=BlackIkeEagle&SeB=m BlackIkeEagle]||[[User:BlackEagle|Ike Devolder]]||ike DOT devolder AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bluewind&SeB=m Bluewind]||Florian Pritz|| bluewind@xinu.at<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=City-busz&SeB=m City-busz]||Balló György||ballogyor+arch at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ConnorBehan&SeB=m ConnorBehan]||Connor Behan||connor.behan@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lfleischer&SeB=m lfleischer]||Lukas Fleischer||lfleischer at archlinux dot org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=eworm&SeB=m eworm]||Christian Hesse||mail@eworm.de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dragonlord&SeB=m Dragonlord]||[[User:Drag0nl0rd|Jaroslav Lichtblau]]||dragonlord @ aur archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dvzrv&SeB=m dvzrv]||[[User:Davezerave|David Runge]]|| dave@sleepmap.de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=faidoc&SeB=m Faidoc]||Alexandre Filgueira||alexfilgueira [at] cinnarch [dot] com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=farseerfc&SeB=m farseerfc]||Jiachen Yang||farseerfc[at]gmail[dot]com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=felixonmars&SeB=m felixonmars]||Felix Yan||felixonmars@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=flexiondotorg&SeB=m flexiondotorg]||Martin Wimpress||[mailto:martin+arch@flexion.org martin+arch@flexion.org]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Foxboron&SeB=m Foxboron]||Morten Linderud||foxboron@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foxxx0&SeB=m foxxx0]||Thore Bödecker||me [at] foxxx0 [dot] de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=giniu&SeB=m giniu]||[[User:giniu|Andrzej Giniewicz]]||gginiu@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=grazzolini grazzolini]||Giancarlo Razzolini||grazzolini [at] gmail [dot] com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gtmanfred&SeB=m gtmanfred]||Daniel Wallace||danielwallace gtmanfred com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=heftig&SeB=m heftig]||Jan Steffens||jan.steffens@student.kit.edu<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jelly&SeB=m jelly]||Jelle van der Waa|| jelle vdwaa nl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jleclanche&SeB=m jleclanche]||[[User:jleclanche|Jerome Leclanche]]||jerome''@''leclan''.''ch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jsteel&SeB=m jsteel]||Jonathan Steel||jsteel at aur.archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=keenerd&SeB=m keenerd]||Kyle Keen||keenerd@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Kyrias&SeB=m Kyrias]||[[User:Kyrias|Johannes Löthberg]]||johannes@kyriasis.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lordheavy&SeB=m Lordheavy]||[[User:Lordheavy|Laurent Carlier]]||lordheavym at gmail com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mtorromeo&SeB=m mtorromeo]||Massimiliano Torromeo||massimiliano.torromeo@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Muflone&SeB=m Muflone]||Fabio Castelli||webreg (at) vbsimple.net<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=NicoHood&SeB=m NicoHood]||NicoHood||archlinux (cat) nicohood (dog) de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schivmeister&SeB=m schivmeister]||[[User:Schivmeister|Ray Rashif]]||schiv archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schuay&SeB=m schuay]||Jakob Gruber||jakob.gruber@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=seblu&SeB=m seblu]||Sébastien Luttringer||s е b l u ''at'' a r c h l і n ux ''dot'' o r g<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=sergej&SeB=m sergej]||[[User:Sergej|Sergej Pupykin]]||pupykin.s+arch@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shibumi&SeB=m shibumi]||[[User:shibumi|Christian Rebischke]]||Chris.Rebischke [at] archlinux [dot] org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=speps&SeB=m speps]||SpepS||dreamspepser at yahoo dot it<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=stativ&SeB=m stativ]||Lukas Jirkovsky||l.jirkovsky strange_curved_character gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=svenstaro&SeB=m svenstaro]||[[User:svenstaro|Sven-Hendrik Haase]]||sh@lutzhaase.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=td123&SeB=m td123]||Thomas Dziedzic||gostrc at gmail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tensor5&SeB=m tensor5]||Nicola Squartini||tensor5@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tredaelli&SeB=m tredaelli]||Timothy Redaelli||timothy.redaelli@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wild&SeB=m wild]||[[User:vild|Dan Printzell]]||[mailto:arch@vild.io arch@vild.io]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Xyne&SeB=m Xyne]||Xyne||ca . archlinux @ xyne, in reverse order<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=xyproto&SeB=m xyproto]||Alexander Rødseth||rodseth@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=zorun&SeB=m zorun]||Baptiste Jonglez||archlinux bitsofnetworks org<br />
|}<br />
<br />
== Inactive Trusted Users ==<br />
{| class="wikitable"<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|style="font-weight: bold;"|E-Mail<br />
|style="font-weight: bold;"|Comments/Reference<br />
|-<br />
|}<br />
<br />
== Some Past Trusted Users ==<br />
{| class="wikitable"<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=abhidg&SeB=m abhidg]||Abhishek Dasgupta<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Allan&SeB=m Allan]||Allan McRae<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anders&SeB=m anders]||Anders Bergh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=angvp&SeB=m angvp]||[[User:Angvp|Angel Velásquez]]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bardo&SeB=m bardo]||Corrado Primier<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ndr&SeB=m ndr]||Andrea Scarpino<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bfinch&SeB=m bfinch]||Bob Finch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=brain0&SeB=m brain0]||Thomas Bächler<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bjorn&SeB=m bjorn]||[[User:Bjørn|Bjørn Lindeijer]]<br />
|- <br />
|[https://aur.archlinux.org/packages/?K=Cinelli&SeB=m cinelli] ||Federico Cinelli<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=codemac&SeB=m codemac]||Jeff Mickey<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=cmb&SeB=m cmb]||Chris Brannon<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Daenyth&SeB=m Daenyth]||Daenyth Blank<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=DaNiMoTh&SeB=m DaNiMoTh]||JJ. DaNiMoTh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dejari&SeB=m dejari]||Leslie P. Polzer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dsa&SeB=m dsa]||Douglas Soares de Andrade<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dtw&SeB=m dtw]||Phil Dillon-Thiselton<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=elasticdog&SeB=m elasticdog]||Aaron Bull Schaefer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=encelo&SeB=m encelo]||Angelo Theodorou<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=even&SeB=m even] ||Kessia Pinheiro<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=falconindy&SeB=m falconindy]||Dave Reisner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foutrelis&SeB=m foutrelis]||Evangelos Foutras<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=filoktetes&SeB=m filoktetes]||Robert Emil Berge<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=firmicus&SeB=m firmicus]||François Charette<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ganja_guru&SeB=m ganja_guru]||Varun Acharya<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gcarrier&SeB=m gcarrier]||Geoffroy Carrier<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ghost1227&SeB=m Ghost1227]||Dan Griffiths<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gummibaerchen&SeB=m gummibaerchen]||Timm Preetz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=hdoria&SeB=m hdoria]||Hugo Doria<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=iphitus&SeB=m iphitus]||James Rayner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=itsbrad212&SeB=m itsbrad212]||Brad Fanella<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=kaitocracy&SeB=m kaitocracy]||Kaiting Chen<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=louipc&SeB=m louipc]||Loui Chang<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mOLOk&SeB=m mOLOk]||Alessio Bolognino<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=nesl247&SeB=m nesl247]||Alex Heck<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Neverth&SeB=m Neverth]||Mikko Seppälä<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Partition&SeB=m Partition]||Mateusz Herych<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=petelewis&SeB=m petelewis]||Peter Lewis<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=PirateJonno&SeB=m PirateJonno]||Jonathan Conder<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=phrakture&SeB=m phrakture]||Aaron Griffin<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Pierre&SeB=m Pierre]||Pierre Schmitz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pizzapunk&SeB=m pizzapunk]||Alexander Fehr<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pjmattal&SeB=m pjmattal]||Paul Mattal<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pressh&SeB=m pressh]||Ronald van Haren<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ranguvar&SeB=m Ranguvar]||Devin Cofer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Romashka&SeB=m Romashka]||Roman Kyrylych<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shastry&SeB=m shastry]||Vinay S Shastry<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Snowman&SeB=m Snowman]||Eric Bélanger<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shinlun&SeB=m shinlun]||Shinlun Hsieh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=StefanHusmann&SeB=m StefanHusmann]||Stefan Husmann<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=STiAT&SeB=m STiAT]||Georg Grabler<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=swiergot&SeB=m swiergot]||Jaroslaw Swierczynski<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tardo&SeB=m tardo]||Shehzad Qureshi<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thatch45&SeB=m thatch45]||Thomas S Hatch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thotypous&SeB=m thotypous]||Paulo Matias<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=vegai&SeB=m vegai]||Vesa Kaihlavirta<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=voidnull&SeB=m voidnull]||Giovanni Scafora<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wizzomafizzo&SeB=m wizzomafizzo]||Callan Barrett<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wonder&SeB=m wonder]|| Ionut Biru<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Xilon&SeB=m Xilon]||Sebastian Nowicki<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=xterminus&SeB=m xterminus]||Charles Mauch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=zeus&SeB=m zeus]||Zhukov Pavel<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dicebot&SeB=m Dicebot]||Mihails Strasuns<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thestinger&SeB=m thestinger]||Daniel Micay<br />
|}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Package_Maintainers&diff=497277Package Maintainers2017-11-18T18:05:41Z<p>Thestinger: move self to past tus</p>
<hr />
<div>[[Category:Arch development]]<br />
[[fr:TU]]<br />
[[ja:Trusted Users]]<br />
[[pt:Trusted Users]]<br />
The [https://www.archlinux.org/people/trusted-users/ Trusted Users] serve the following purposes:<br />
# Maintain the ''community'' repository as an intermediary between Arch Linux's [[official repositories]] and the unsupported package collection in the [[AUR]].<br />
# Maintain, manage, and watch over the operation of the [[AUR]].<br />
<br />
== How do I become a TU? ==<br />
The ''minimum'' requirements to becoming a TU are as follows:<br />
* know basic shell scripting<br />
* maintain a few packages in AUR with clean, high-quality PKGBUILDs<br />
* basic community involvement (mailing list, forums, IRC)<br />
* know Google-Fu<br />
* a general idea of the kind of packages you want to maintain (basically, why do you want to become TU?)<br />
<br />
<br />
Even though you could become a TU by merely fulfilling those minimum requirements, the people judging you [https://aur.archlinux.org/trusted-user/TUbylaws.html#_standard_voting_procedure during voting] might expect more of you. Such as:<br />
* involvement in the bug tracker (reporting, research, info)<br />
* patches for Arch projects<br />
* involvement in a few open-source projects (even if they are your own)<br />
<br />
<br />
In case you still feel up to becoming a TU after reading these lists, you should find another TU to sponsor you and write a witty application signed with your GPG key to the aur-general mailing list.<br />
<br />
{{Note|Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU.}}<br />
<br />
For more information, please see [https://aur.archlinux.org/trusted-user/TUbylaws.html Trusted User Bylaws] and [[AUR Trusted User Guidelines]].<br />
<br />
== Active Trusted Users ==<br />
{| class="wikitable"<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|style="font-weight: bold;"|E-Mail<br />
|-<br />
|[https://aur.archlinux.org/packages/?K=Alad&SeB=m alad]||[[User:Alad|Alad Wenter]]||nynq ng znvyobk qbg bet (rot13)<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=alucryd&SeB=m alucryd]||Maxime Gauduin||alucryd@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ambrevar&SeB=m Ambrevar]||[[User:Ambrevar|Pierre Neidhardt]]||ambrevar@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anatolik&SeB=m anatolik]||Anatol Pomozov||anatol dot pomozov + arch at gmail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anthraxx&SeB=m anthraxx]||[[User:anthraxx|Levente Polyak]]||anthraxx [at] archlinux [dot] org<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=arcanis arcanis]||Evgeniy Alekseev||arcanis DOT arch AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ArchangeGabriel&SeB=m ArchangeGabriel]||Bruno Pagani||bruno.n.pagani@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=arojas arojas]||Antonio Rojas||arojas@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Atsutane&SeB=m Atsutane]||Thorsten Töpper||atsutane {0x40} freethoughts {0x2E} de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Barthalion&SeB=m Barthalion]||Bartłomiej Piotrowski||spam@bpiotrowski.pl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=BlackIkeEagle&SeB=m BlackIkeEagle]||[[User:BlackEagle|Ike Devolder]]||ike DOT devolder AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bluewind&SeB=m Bluewind]||Florian Pritz|| bluewind@xinu.at<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=City-busz&SeB=m City-busz]||Balló György||ballogyor+arch at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ConnorBehan&SeB=m ConnorBehan]||Connor Behan||connor.behan@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lfleischer&SeB=m lfleischer]||Lukas Fleischer||lfleischer at archlinux dot org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=eworm&SeB=m eworm]||Christian Hesse||mail@eworm.de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dragonlord&SeB=m Dragonlord]||[[User:Drag0nl0rd|Jaroslav Lichtblau]]||dragonlord @ aur archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dvzrv&SeB=m dvzrv]||[[User:Davezerave|David Runge]]|| dave@sleepmap.de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=faidoc&SeB=m Faidoc]||Alexandre Filgueira||alexfilgueira [at] cinnarch [dot] com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=farseerfc&SeB=m farseerfc]||Jiachen Yang||farseerfc[at]gmail[dot]com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=felixonmars&SeB=m felixonmars]||Felix Yan||felixonmars@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=flexiondotorg&SeB=m flexiondotorg]||Martin Wimpress||[mailto:martin+arch@flexion.org martin+arch@flexion.org]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Foxboron&SeB=m Foxboron]||Morten Linderud||foxboron@archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foxxx0&SeB=m foxxx0]||Thore Bödecker||me [at] foxxx0 [dot] de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=giniu&SeB=m giniu]||[[User:giniu|Andrzej Giniewicz]]||gginiu@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages/?SeB=m&K=grazzolini grazzolini]||Giancarlo Razzolini||grazzolini [at] gmail [dot] com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gtmanfred&SeB=m gtmanfred]||Daniel Wallace||danielwallace gtmanfred com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=heftig&SeB=m heftig]||Jan Steffens||jan.steffens@student.kit.edu<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jelly&SeB=m jelly]||Jelle van der Waa|| jelle vdwaa nl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jleclanche&SeB=m jleclanche]||[[User:jleclanche|Jerome Leclanche]]||jerome''@''leclan''.''ch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jsteel&SeB=m jsteel]||Jonathan Steel||jsteel at aur.archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=keenerd&SeB=m keenerd]||Kyle Keen||keenerd@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Kyrias&SeB=m Kyrias]||[[User:Kyrias|Johannes Löthberg]]||johannes@kyriasis.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lordheavy&SeB=m Lordheavy]||[[User:Lordheavy|Laurent Carlier]]||lordheavym at gmail com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mtorromeo&SeB=m mtorromeo]||Massimiliano Torromeo||massimiliano.torromeo@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Muflone&SeB=m Muflone]||Fabio Castelli||webreg (at) vbsimple.net<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=NicoHood&SeB=m NicoHood]||NicoHood||archlinux (cat) nicohood (dog) de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schivmeister&SeB=m schivmeister]||[[User:Schivmeister|Ray Rashif]]||schiv archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schuay&SeB=m schuay]||Jakob Gruber||jakob.gruber@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=seblu&SeB=m seblu]||Sébastien Luttringer||s е b l u ''at'' a r c h l і n ux ''dot'' o r g<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=sergej&SeB=m sergej]||[[User:Sergej|Sergej Pupykin]]||pupykin.s+arch@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shibumi&SeB=m shibumi]||[[User:shibumi|Christian Rebischke]]||Chris.Rebischke [at] archlinux [dot] org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=speps&SeB=m speps]||SpepS||dreamspepser at yahoo dot it<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=stativ&SeB=m stativ]||Lukas Jirkovsky||l.jirkovsky strange_curved_character gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=svenstaro&SeB=m svenstaro]||[[User:svenstaro|Sven-Hendrik Haase]]||sh@lutzhaase.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=td123&SeB=m td123]||Thomas Dziedzic||gostrc at gmail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tensor5&SeB=m tensor5]||Nicola Squartini||tensor5@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tredaelli&SeB=m tredaelli]||Timothy Redaelli||timothy.redaelli@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wild&SeB=m wild]||[[User:vild|Dan Printzell]]||[mailto:arch@vild.io arch@vild.io]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Xyne&SeB=m Xyne]||Xyne||ca . archlinux @ xyne, in reverse order<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=xyproto&SeB=m xyproto]||Alexander Rødseth||rodseth@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=zorun&SeB=m zorun]||Baptiste Jonglez||archlinux bitsofnetworks org<br />
|}<br />
<br />
== Inactive Trusted Users ==<br />
{| class="wikitable"<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|style="font-weight: bold;"|E-Mail<br />
|style="font-weight: bold;"|Comments/Reference<br />
|-<br />
|}<br />
<br />
== Some Past Trusted Users ==<br />
{| class="wikitable"<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=abhidg&SeB=m abhidg]||Abhishek Dasgupta<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Allan&SeB=m Allan]||Allan McRae<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=anders&SeB=m anders]||Anders Bergh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=angvp&SeB=m angvp]||[[User:Angvp|Angel Velásquez]]<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bardo&SeB=m bardo]||Corrado Primier<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ndr&SeB=m ndr]||Andrea Scarpino<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bfinch&SeB=m bfinch]||Bob Finch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=brain0&SeB=m brain0]||Thomas Bächler<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bjorn&SeB=m bjorn]||[[User:Bjørn|Bjørn Lindeijer]]<br />
|- <br />
|[https://aur.archlinux.org/packages/?K=Cinelli&SeB=m cinelli] ||Federico Cinelli<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=codemac&SeB=m codemac]||Jeff Mickey<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=cmb&SeB=m cmb]||Chris Brannon<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Daenyth&SeB=m Daenyth]||Daenyth Blank<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=DaNiMoTh&SeB=m DaNiMoTh]||JJ. DaNiMoTh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dejari&SeB=m dejari]||Leslie P. Polzer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dsa&SeB=m dsa]||Douglas Soares de Andrade<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=dtw&SeB=m dtw]||Phil Dillon-Thiselton<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=elasticdog&SeB=m elasticdog]||Aaron Bull Schaefer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=encelo&SeB=m encelo]||Angelo Theodorou<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=even&SeB=m even] ||Kessia Pinheiro<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=falconindy&SeB=m falconindy]||Dave Reisner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foutrelis&SeB=m foutrelis]||Evangelos Foutras<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=filoktetes&SeB=m filoktetes]||Robert Emil Berge<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=firmicus&SeB=m firmicus]||François Charette<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ganja_guru&SeB=m ganja_guru]||Varun Acharya<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gcarrier&SeB=m gcarrier]||Geoffroy Carrier<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ghost1227&SeB=m Ghost1227]||Dan Griffiths<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=gummibaerchen&SeB=m gummibaerchen]||Timm Preetz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=hdoria&SeB=m hdoria]||Hugo Doria<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=iphitus&SeB=m iphitus]||James Rayner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=itsbrad212&SeB=m itsbrad212]||Brad Fanella<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=kaitocracy&SeB=m kaitocracy]||Kaiting Chen<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=louipc&SeB=m louipc]||Loui Chang<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mOLOk&SeB=m mOLOk]||Alessio Bolognino<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=nesl247&SeB=m nesl247]||Alex Heck<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Neverth&SeB=m Neverth]||Mikko Seppälä<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Partition&SeB=m Partition]||Mateusz Herych<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=petelewis&SeB=m petelewis]||Peter Lewis<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=PirateJonno&SeB=m PirateJonno]||Jonathan Conder<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=phrakture&SeB=m phrakture]||Aaron Griffin<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Pierre&SeB=m Pierre]||Pierre Schmitz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pizzapunk&SeB=m pizzapunk]||Alexander Fehr<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pjmattal&SeB=m pjmattal]||Paul Mattal<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pressh&SeB=m pressh]||Ronald van Haren<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Ranguvar&SeB=m Ranguvar]||Devin Cofer<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Romashka&SeB=m Romashka]||Roman Kyrylych<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shastry&SeB=m shastry]||Vinay S Shastry<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Snowman&SeB=m Snowman]||Eric Bélanger<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=shinlun&SeB=m shinlun]||Shinlun Hsieh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=StefanHusmann&SeB=m StefanHusmann]||Stefan Husmann<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=STiAT&SeB=m STiAT]||Georg Grabler<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=swiergot&SeB=m swiergot]||Jaroslaw Swierczynski<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tardo&SeB=m tardo]||Shehzad Qureshi<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thatch45&SeB=m thatch45]||Thomas S Hatch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thotypous&SeB=m thotypous]||Paulo Matias<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=vegai&SeB=m vegai]||Vesa Kaihlavirta<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=voidnull&SeB=m voidnull]||Giovanni Scafora<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wizzomafizzo&SeB=m wizzomafizzo]||Callan Barrett<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=wonder&SeB=m wonder]|| Ionut Biru<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Xilon&SeB=m Xilon]||Sebastian Nowicki<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=xterminus&SeB=m xterminus]||Charles Mauch<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=zeus&SeB=m zeus]||Zhukov Pavel<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dicebot&SeB=m Dicebot]||Mihails Strasuns<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=thestinger&SeB=m thestinger]||Daniel Micay||[mailto:danielmicay@gmail.com danielmicay@gmail.com]<br />
|}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=ArchWiki:Administrators&diff=497196ArchWiki:Administrators2017-11-18T01:46:27Z<p>Thestinger: retiring from admin position</p>
<hr />
<div>[[Category:ArchWiki]]<br />
Use the ''discussion'' tab above each page for page-specific comments. Use [[ArchWiki talk:Administrators]] for generic remarks.<br />
<br />
Contact one of the Administrators for private discussions:<br />
<br />
<!--START AUTO LIST - DO NOT REMOVE OR MODIFY THIS MARK--><br />
* [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) - [[Special:EmailUser/Fengchao|Send Email]]<br />
* [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) - [[Special:EmailUser/Lahwaacz|j.l.k@gmx.com]]<br />
* [[User:Alad|Alad]] ([[User talk:Alad|talk]]) - [[User talk:Alad|Send Message]]<br />
* [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) - [[Special:EmailUser/Kynikos|dario<span style="display:none;"> {nospam} </span>gio<span style="display:none;display:inherit;">va&#64;gm</span>ai<span style="display:none;"> {nospam} </span>l&#46;com]]<br />
<br />
The following Administrators are currently inactive (less than 30 edits in the last 30 days):<br />
<br />
* [[User:jasonwryan|jasonwryan]] ([[User talk:jasonwryan|talk]]) - [[Special:EmailUser/jasonwryan|jasonwryan@gmail.com]]<br />
* [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) - [[Special:EmailUser/Indigo|ialbrecht@gmx.net]]<br />
* [[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]]) - [[Special:EmailUser/Misfit138|pitsker@gmail.com]]<br />
* [[User:pointone|pointone]] ([[User talk:pointone|talk]]) - [[Special:EmailUser/pointone|desmondgc@gmail.com]]<br />
<!--END AUTO LIST - DO NOT REMOVE OR MODIFY THIS MARK--><br />
<br />
Members are periodically and automatically sorted in descending order by their number of edits in the previous 30 days.</div>Thestingerhttps://wiki.archlinux.org/index.php?title=User:Thestinger&diff=495183User:Thestinger2017-11-04T23:05:04Z<p>Thestinger: Removed protection from "User:Thestinger"</p>
<hr />
<div>{{DISPLAYTITLE:User:thestinger}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=User:Thestinger&diff=481889User:Thestinger2017-07-14T07:20:22Z<p>Thestinger: rm</p>
<hr />
<div>{{DISPLAYTITLE:User:thestinger}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=481681Security2017-07-11T07:02:57Z<p>Thestinger: /* 32-bit processes (on an x86_64 kernel) */ add linux results</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=481676Security2017-07-11T06:48:23Z<p>Thestinger: /* 32-bit processes (on the x86_64 kernel) */ the -> an</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=481675Security2017-07-11T06:47:21Z<p>Thestinger: /* Userspace ASLR comparison */ add 32-bit process results for linux-hardened</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
===== 32-bit processes (on the x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Security&diff=478860DeveloperWiki:Security2017-05-31T19:34:00Z<p>Thestinger: /* Replacing setuid with capabilities */</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
This page documents progress on fixing/implementing non-CVE security-related bugs and features.<br />
<br />
== Compiler / linker hardening ==<br />
<br />
The current globally enabled hardening flags:<br />
<br />
* CPPFLAGS: -D_FORTIFY_SOURCE=2<br />
* CFLAGS/CXXFLAGS: -fstack-protector-strong<br />
* LDFLAGS: -Wl,-z,relro<br />
<br />
=== Packages not respecting flags ===<br />
<br />
==== Tangible attack surface ====<br />
<br />
* {{pkg|john}} - {{bug|43232}}<br />
* <s>{{pkg|gpsd}} - {{bug|43233}}</s><br />
* {{pkg|bzip2}} - {{bug|43231}}<br />
* {{pkg|festival}} - {{bug|43229}}<br />
* <s>{{pkg|zita-alsa-pcmi}} - {{bug|43230}}</s> - rebuild<br />
* <s>{{pkg|zita-resampler}}</s> - rebuild<br />
* <s>{{pkg|mpv}} - {{bug|43235}}</s> - hardening-wrapper<br />
* <s>{{pkg|ffmpeg}}</s> - hardening-wrapper<br />
* {{pkg|ghostscript}} - {{bug|43234}}<br />
* {{pkg|zip}} - {{bug|43236}}<br />
* <s>{{pkg|unrar}} - {{bug|43237}}</s> - hardening-wrapper<br />
* {{pkg|python}}, {{pkg|python2}} - {{bug|43246}}<br />
* {{pkg|imagemagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
* {{pkg|graphicsmagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
<br />
==== Seemingly no tangible attack surface ====<br />
<br />
{{Note|It would be nice if these were fixed but it doesn't seem worth filing bugs for them.}}<br />
<br />
* {{pkg|dmidecode}}<br />
* {{pkg|boost}}<br />
* {{pkg|gcc}}<br />
* {{pkg|libcap}}<br />
* {{pkg|glew}}<br />
* {{pkg|dmenu}}<br />
* {{pkg|gsl}}<br />
* {{pkg|hdparm}}<br />
* {{pkg|lm_sensors}}<br />
* {{pkg|lsof}}<br />
* {{pkg|procinfo-ng}}<br />
* {{pkg|nethogs}}<br />
* {{AUR|qtchooser}}<br />
* {{pkg|rust}}<br />
<br />
=== Full RELRO ===<br />
<br />
Arch passes {{ic|-z relro}} to the linker in the default {{ic|LDFLAGS}}, causing many internal ELF data sections to be marked read-only. However, passing {{ic|-z now}} to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|chromium}}<br />
* {{pkg|colord}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
=== PIE ===<br />
<br />
[[Wikipedia:ASLR|ASLR]] is enabled by default, and a stronger implementation is available in {{pkg|linux-grsec}}{{Broken package link|{{aur-mirror|linux-grsec}}}}. Data and code addresses in dynamic libraries are always randomized because these are always [[Wikipedia:Position independent code|position independent code]]. However, executables are not position independent by default and cannot take advantage of ASLR. This also applies to important ELF data like the GOT/PLT where many library functions will be referenced, so ASLR is essentially useless without PIE. Passing {{ic|-fPIE}} (or {{ic|-fPIC}}) while compiling and {{ic|-pie}} while linking will enable PIE, but these cannot simply be default flags because it will break libraries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|colord}}<br />
* {{pkg|chromium}}<br />
* {{pkg|cups}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|sudo}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
==== Example ====<br />
<br />
{{hc|aslr.c|<nowiki>#include <stdio.h><br />
<br />
static void foo() {}<br />
static int bar = 5;<br />
<br />
int main(void) {<br />
int baz = 5;<br />
printf("function: %p, library function: %p, data: %p, stack: %p\n", foo, &printf, &bar, &baz);<br />
return 0;<br />
}</nowiki>}}<br />
<br />
{{hc|$ gcc -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff909cac1c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffee85453c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0d05a1ec<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff6e250bbc<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff4889ec7c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0eb22b5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffdce51a0c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff8c42db5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffce276c2c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffedbb9ffc<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400516, library function: 0x7f1e55a3e150, data: 0x6009c0, stack: 0x7fff7ce9317c<br />
function: 0x400516, library function: 0x7ffae3294150, data: 0x6009c0, stack: 0x7fff428a8e1c<br />
function: 0x400516, library function: 0x7f39c4ed6150, data: 0x6009c0, stack: 0x7fffdb57db5c<br />
function: 0x400516, library function: 0x7f8e4fccd150, data: 0x6009c0, stack: 0x7ffffd46bd3c<br />
function: 0x400516, library function: 0x7f885508b150, data: 0x6009c0, stack: 0x7fffe7bf69cc<br />
function: 0x400516, library function: 0x7ffa9a05f150, data: 0x6009c0, stack: 0x7ffff89fdfac<br />
function: 0x400516, library function: 0x7ffe6114d150, data: 0x6009c0, stack: 0x7fff888accdc<br />
function: 0x400516, library function: 0x7f30f1893150, data: 0x6009c0, stack: 0x7fff2cfcb6bc<br />
function: 0x400516, library function: 0x7fd9e91dc150, data: 0x6009c0, stack: 0x7fff91c0062c<br />
function: 0x400516, library function: 0x7fdf4c136150, data: 0x6009c0, stack: 0x7fff7f96928c<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -pie -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x7f35659b4770, library function: 0x7f3565433150, data: 0x7f3565bb4c38, stack: 0x7ffff3de9a4c<br />
function: 0x7f173ab2b770, library function: 0x7f173a5aa150, data: 0x7f173ad2bc38, stack: 0x7fffa0e7b12c<br />
function: 0x7ff59b960770, library function: 0x7ff59b3df150, data: 0x7ff59bb60c38, stack: 0x7fffaca2f8cc<br />
function: 0x7f557c39e770, library function: 0x7f557be1d150, data: 0x7f557c59ec38, stack: 0x7fff9127b98c<br />
function: 0x7f1bc8f53770, library function: 0x7f1bc89d2150, data: 0x7f1bc9153c38, stack: 0x7fff75d767ac<br />
function: 0x7f8af81e8770, library function: 0x7f8af7c67150, data: 0x7f8af83e8c38, stack: 0x7fff4bb7856c<br />
function: 0x7f8be8334770, library function: 0x7f8be7db3150, data: 0x7f8be8534c38, stack: 0x7fffcf8b33cc<br />
function: 0x7f3c246a5770, library function: 0x7f3c24124150, data: 0x7f3c248a5c38, stack: 0x7fffb25d8ccc<br />
function: 0x7fa457c39770, library function: 0x7fa4576b8150, data: 0x7fa457e39c38, stack: 0x7fffc92d85fc<br />
function: 0x7f1dffbb8770, library function: 0x7f1dff637150, data: 0x7f1dffdb8c38, stack: 0x7fffd2bfff2c}}<br />
<br />
=== hardening-wrapper ===<br />
<br />
The {{pkg|hardening-wrapper}} package wraps C and C++ compilers in order to enable the chosen hardening flags by default for all builds. A wrapper (or patched toolchain) is a hard requirement for enabling PIE for all packages, because different flags need to be passed depending on whether an executable or library is being compiled. Enabling PIE by default on x86_64 should be pursued, and this is likely the best way to do it.<br />
<br />
== non-root X ==<br />
<br />
The {{pkg|xorg-server}} package now ships with {{ic|/usr/bin/Xorg}} as a wrapper script, calling the {{ic|/usr/bin/Xorg.wrap}} setuid binary and dropping privileges if possible (video driver with [[KMS]]). To decrease the attack surface, the setuid should be split into a separate package and added as a dependency to drivers without rootless X support. The script is already set up to fall back to {{ic|/usr/bin/Xorg.bin}} if the wrapper is unavailable.<br />
<br />
{{bug|41257}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Security&diff=478859DeveloperWiki:Security2017-05-31T19:33:50Z<p>Thestinger: /* Service Isolation */ give up on this for now</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
This page documents progress on fixing/implementing non-CVE security-related bugs and features.<br />
<br />
== Replacing setuid with capabilities ==<br />
<br />
This is a scratch space tracking which packages still include setuid binaries and replacing these with capabilities where possible. Reducing setuid to CAP_SYS_ADMIN or any capabilities allowing escalation to root access is not very useful (at least without MAC/RBAC backing it up), so it will not be covered (yet?).<br />
<br />
* <s>{{Bug|39686}} - [inetutils] rsh, rcp and rlogin should use cap_net_bind_service, not setuid</s><br />
* {{pkg|sudo}} - requires setuid<br />
<br />
== Compiler / linker hardening ==<br />
<br />
The current globally enabled hardening flags:<br />
<br />
* CPPFLAGS: -D_FORTIFY_SOURCE=2<br />
* CFLAGS/CXXFLAGS: -fstack-protector-strong<br />
* LDFLAGS: -Wl,-z,relro<br />
<br />
=== Packages not respecting flags ===<br />
<br />
==== Tangible attack surface ====<br />
<br />
* {{pkg|john}} - {{bug|43232}}<br />
* <s>{{pkg|gpsd}} - {{bug|43233}}</s><br />
* {{pkg|bzip2}} - {{bug|43231}}<br />
* {{pkg|festival}} - {{bug|43229}}<br />
* <s>{{pkg|zita-alsa-pcmi}} - {{bug|43230}}</s> - rebuild<br />
* <s>{{pkg|zita-resampler}}</s> - rebuild<br />
* <s>{{pkg|mpv}} - {{bug|43235}}</s> - hardening-wrapper<br />
* <s>{{pkg|ffmpeg}}</s> - hardening-wrapper<br />
* {{pkg|ghostscript}} - {{bug|43234}}<br />
* {{pkg|zip}} - {{bug|43236}}<br />
* <s>{{pkg|unrar}} - {{bug|43237}}</s> - hardening-wrapper<br />
* {{pkg|python}}, {{pkg|python2}} - {{bug|43246}}<br />
* {{pkg|imagemagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
* {{pkg|graphicsmagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
<br />
==== Seemingly no tangible attack surface ====<br />
<br />
{{Note|It would be nice if these were fixed but it doesn't seem worth filing bugs for them.}}<br />
<br />
* {{pkg|dmidecode}}<br />
* {{pkg|boost}}<br />
* {{pkg|gcc}}<br />
* {{pkg|libcap}}<br />
* {{pkg|glew}}<br />
* {{pkg|dmenu}}<br />
* {{pkg|gsl}}<br />
* {{pkg|hdparm}}<br />
* {{pkg|lm_sensors}}<br />
* {{pkg|lsof}}<br />
* {{pkg|procinfo-ng}}<br />
* {{pkg|nethogs}}<br />
* {{AUR|qtchooser}}<br />
* {{pkg|rust}}<br />
<br />
=== Full RELRO ===<br />
<br />
Arch passes {{ic|-z relro}} to the linker in the default {{ic|LDFLAGS}}, causing many internal ELF data sections to be marked read-only. However, passing {{ic|-z now}} to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|chromium}}<br />
* {{pkg|colord}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
=== PIE ===<br />
<br />
[[Wikipedia:ASLR|ASLR]] is enabled by default, and a stronger implementation is available in {{pkg|linux-grsec}}{{Broken package link|{{aur-mirror|linux-grsec}}}}. Data and code addresses in dynamic libraries are always randomized because these are always [[Wikipedia:Position independent code|position independent code]]. However, executables are not position independent by default and cannot take advantage of ASLR. This also applies to important ELF data like the GOT/PLT where many library functions will be referenced, so ASLR is essentially useless without PIE. Passing {{ic|-fPIE}} (or {{ic|-fPIC}}) while compiling and {{ic|-pie}} while linking will enable PIE, but these cannot simply be default flags because it will break libraries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|colord}}<br />
* {{pkg|chromium}}<br />
* {{pkg|cups}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|sudo}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
==== Example ====<br />
<br />
{{hc|aslr.c|<nowiki>#include <stdio.h><br />
<br />
static void foo() {}<br />
static int bar = 5;<br />
<br />
int main(void) {<br />
int baz = 5;<br />
printf("function: %p, library function: %p, data: %p, stack: %p\n", foo, &printf, &bar, &baz);<br />
return 0;<br />
}</nowiki>}}<br />
<br />
{{hc|$ gcc -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff909cac1c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffee85453c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0d05a1ec<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff6e250bbc<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff4889ec7c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0eb22b5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffdce51a0c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff8c42db5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffce276c2c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffedbb9ffc<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400516, library function: 0x7f1e55a3e150, data: 0x6009c0, stack: 0x7fff7ce9317c<br />
function: 0x400516, library function: 0x7ffae3294150, data: 0x6009c0, stack: 0x7fff428a8e1c<br />
function: 0x400516, library function: 0x7f39c4ed6150, data: 0x6009c0, stack: 0x7fffdb57db5c<br />
function: 0x400516, library function: 0x7f8e4fccd150, data: 0x6009c0, stack: 0x7ffffd46bd3c<br />
function: 0x400516, library function: 0x7f885508b150, data: 0x6009c0, stack: 0x7fffe7bf69cc<br />
function: 0x400516, library function: 0x7ffa9a05f150, data: 0x6009c0, stack: 0x7ffff89fdfac<br />
function: 0x400516, library function: 0x7ffe6114d150, data: 0x6009c0, stack: 0x7fff888accdc<br />
function: 0x400516, library function: 0x7f30f1893150, data: 0x6009c0, stack: 0x7fff2cfcb6bc<br />
function: 0x400516, library function: 0x7fd9e91dc150, data: 0x6009c0, stack: 0x7fff91c0062c<br />
function: 0x400516, library function: 0x7fdf4c136150, data: 0x6009c0, stack: 0x7fff7f96928c<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -pie -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x7f35659b4770, library function: 0x7f3565433150, data: 0x7f3565bb4c38, stack: 0x7ffff3de9a4c<br />
function: 0x7f173ab2b770, library function: 0x7f173a5aa150, data: 0x7f173ad2bc38, stack: 0x7fffa0e7b12c<br />
function: 0x7ff59b960770, library function: 0x7ff59b3df150, data: 0x7ff59bb60c38, stack: 0x7fffaca2f8cc<br />
function: 0x7f557c39e770, library function: 0x7f557be1d150, data: 0x7f557c59ec38, stack: 0x7fff9127b98c<br />
function: 0x7f1bc8f53770, library function: 0x7f1bc89d2150, data: 0x7f1bc9153c38, stack: 0x7fff75d767ac<br />
function: 0x7f8af81e8770, library function: 0x7f8af7c67150, data: 0x7f8af83e8c38, stack: 0x7fff4bb7856c<br />
function: 0x7f8be8334770, library function: 0x7f8be7db3150, data: 0x7f8be8534c38, stack: 0x7fffcf8b33cc<br />
function: 0x7f3c246a5770, library function: 0x7f3c24124150, data: 0x7f3c248a5c38, stack: 0x7fffb25d8ccc<br />
function: 0x7fa457c39770, library function: 0x7fa4576b8150, data: 0x7fa457e39c38, stack: 0x7fffc92d85fc<br />
function: 0x7f1dffbb8770, library function: 0x7f1dff637150, data: 0x7f1dffdb8c38, stack: 0x7fffd2bfff2c}}<br />
<br />
=== hardening-wrapper ===<br />
<br />
The {{pkg|hardening-wrapper}} package wraps C and C++ compilers in order to enable the chosen hardening flags by default for all builds. A wrapper (or patched toolchain) is a hard requirement for enabling PIE for all packages, because different flags need to be passed depending on whether an executable or library is being compiled. Enabling PIE by default on x86_64 should be pursued, and this is likely the best way to do it.<br />
<br />
== non-root X ==<br />
<br />
The {{pkg|xorg-server}} package now ships with {{ic|/usr/bin/Xorg}} as a wrapper script, calling the {{ic|/usr/bin/Xorg.wrap}} setuid binary and dropping privileges if possible (video driver with [[KMS]]). To decrease the attack surface, the setuid should be split into a separate package and added as a dependency to drivers without rootless X support. The script is already set up to fall back to {{ic|/usr/bin/Xorg.bin}} if the wrapper is unavailable.<br />
<br />
{{bug|41257}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=478839Security2017-05-31T17:36:48Z<p>Thestinger: /* Kernel hardening */stop mentioning PaX and grsecurity to avoid trademark issues</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=478703Security2017-05-31T00:30:40Z<p>Thestinger: /* Userspace ASLR comparison */update paxtest output again</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. It currently offers a subset of the features of the previous {{ic|linux-grsec}} package before PaX and grsecurity became fully private commercial-only patches. The intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. It provides close to the same ASLR quality as PaX/grsecurity. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=478659Security2017-05-30T11:56:22Z<p>Thestinger: /* Userspace ASLR comparison */update linux-hardened paxtest ASLR output</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. It currently offers a subset of the features of the previous {{ic|linux-grsec}} package before PaX and grsecurity became fully private commercial-only patches. The intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. It provides close to the same ASLR quality as PaX/grsecurity. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 18 quality bits (guessed)<br />
Heap randomization test (PIE) : 32 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=478637Security2017-05-30T07:06:30Z<p>Thestinger: /* Kernel self-protection / exploit mitigation */rw</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. It currently offers a subset of the features of the previous {{ic|linux-grsec}} package before PaX and grsecurity became fully private commercial-only patches. The intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. It provides close to the same ASLR quality as PaX/grsecurity but does not yet improve heap randomization beyond the improvement from better executation randomization. The {{pkg|paxtest}} command can be used to estimate the provided entropy:<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 32 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=478635Security2017-05-30T06:44:43Z<p>Thestinger: /* Kernel self-protection / exploit mitigation */ paxtest output</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. It provides close to the same ASLR quality as PaX/grsecurity but does not yet improve heap randomization beyond the improvement from better executation randomization. The {{pkg|paxtest}} command can be used to estimate the provided entropy:<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 32 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)}}<br />
<br />
{{hc|linux|Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Security&diff=476148DeveloperWiki:Security2017-05-07T18:10:06Z<p>Thestinger: /* kernel hardening */ give up on this</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
This page documents progress on fixing/implementing non-CVE security-related bugs and features.<br />
<br />
== Service Isolation ==<br />
<br />
Green cells indicate a security feature is implemented, and red cells indicate the lack of a feature. If it's not possible to implement a feature without losing functionality (even if off-by-default), a reason is given instead. This also applies to features that are simply not useful, such as PrivateTmp for services without any usage of {{ic|/tmp}} as these can be handled with InaccessibleDirectories.<br />
<br />
A red cell without a link to an issue report indicates that research/testing is required in order to either mark it as not possible or report an issue. <br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Package !! Service !! User !! Group !! PrivateDevices !! PrivateNetwork !! PrivateTmp<br />
|-<br />
| {{pkg|chrony}} || {{ic|chrony.service}} || {{G|chrony}} || {{G|chrony}} || can use {{ic|/dev/rtc}} || n/a || {{no}}<br />
|-<br />
| {{pkg|cronie}} || {{ic|cronie.service}} || root (jobs) || root (jobs) || jobs || jobs || jobs<br />
|-<br />
| {{pkg|lighttpd}} || {{ic|lighttpd.service}} || {{G|http}} || {{G|http}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|paxd}}{{Broken package link|package not found}} || {{ic|paxd.service}} || root (xattrs) || root (xattrs) || {{no}} || {{no}} || not used <br />
|-<br />
| {{pkg|pdnsd}} || {{ic|pdnsd.service}} || {{G|pdnsd}} || {{G|pdnsd}} || can use {{ic|/dev/isdninfo}} || n/a || not used <br />
|-<br />
| {{pkg|polipo}} || {{ic|polipo.service}} || {{G|polipo}} || {{G|polipo}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|polkit}} || {{ic|polkit.service}} || {{G|polkitd}} || {{G|polkitd}} || rules || rules || rules<br />
|-<br />
| {{pkg|privoxy}} || {{ic|privoxy.service}} || {{G|privoxy}} || {{G|privoxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|networkmanager}} || {{ic|NetworkManager.service}} || {{R|root}} || {{R|root}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|nginx}} || {{ic|nginx.service}} || {{G|http}} || {{G|http}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| rowspan=2 | {{pkg|ntp}} || {{ic|ntpdate.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{ic|ntpd.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|tor}} || {{ic|tor.service}} || {{G|tor}} || {{G|tor}} || {{yes}} || n/a || not used<br />
|-<br />
| {{pkg|tinyproxy}} || {{ic|tinyproxy.service}} || {{G|tinyproxy}} || {{G|tinyproxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|transmission-cli}} || {{ic|transmission.service}} || {{G|transmission}} || {{G|transmission}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|wpa_supplicant}} || {{ic|wpa_supplicant.service}} || {{R|root}} || {{R|root}} || {{no}} || {{no}} || {{no}}<br />
|-<br />
| {{pkg|znc}} || {{ic|znc.service}} || {{G|znc}} || {{G|znc}} || {{no}} || n/a || {{no}}<br />
|-<br />
|}<br />
<br />
=== User/Group ===<br />
<br />
In nearly every case, services should use an unprivileged user rather than running as root. Some cases may require the use of capabilities like CAP_NET_ADMIN or CAP_NET_BIND_SERVICE. Some exceptions are cron daemons, since they need to run scripts as root and anything needing CAP_SYS_ADMIN or a similar capability essentially equivalent to root access.<br />
<br />
It is '''not''' appropriate to run services as {{ic|nobody}}. If this user is shared among more than one service, then they are vulnerable to each other. For example, consider a caching dns server (pdnsd) running as nobody alongside ntpd running as nobody. If ntpd is compromised via a vulnerability, all the attacker should be able to do is mess with the time. However, thanks to the use of {{ic|nobody}} they will be able to intercept/modify all dns requests and alter the persistent cache.<br />
<br />
=== PrivateDevices ===<br />
<br />
If there is absolutely no usage of {{ic|/dev/}}, then {{ic|InaccessibleDirectories}} combined with {{ic|1=DevicePolicy=strict}} is a valid alternative.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateNetwork ===<br />
<br />
This can be used for any service without a need for network communication beyond sockets provided through socket activation.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateTmp ===<br />
<br />
This should only be used if a service needs to make use of {{ic|/tmp}}. Bash makes extensive use of {{ic|/tmp}} for stuff like here documents, so any shell usage is enough to make it worthwhile.<br />
<br />
https://fedoraproject.org/wiki/Features/ServicesPrivateTmp<br />
<br />
=== ReadOnly/ReadWrite ===<br />
<br />
systemd has some basic MAC capabilities (InaccessibleDirectories, ReadWriteDirectories, ReadOnlyDirectories), but is limited to directories since it's based on bind mounts in a mount namespace. These features do not currently have the ability to recurse into submounts, causing the increase in security to be misleading. It doesn't appear that a whitelist model will work yet either, so it's far from providing true isolation at this point.<br />
<br />
=== NetworkManager / wpa_supplicant ===<br />
<br />
It might be possible to drop nearly all capabilities other than CAP_NET_ADMIN. Of course, if these need CAP_SYS_ADMIN for something there's no point.<br />
<br />
== Replacing setuid with capabilities ==<br />
<br />
This is a scratch space tracking which packages still include setuid binaries and replacing these with capabilities where possible. Reducing setuid to CAP_SYS_ADMIN or any capabilities allowing escalation to root access is not very useful (at least without MAC/RBAC backing it up), so it will not be covered (yet?).<br />
<br />
* <s>{{Bug|39686}} - [inetutils] rsh, rcp and rlogin should use cap_net_bind_service, not setuid</s><br />
* {{pkg|sudo}} - requires setuid<br />
<br />
== Compiler / linker hardening ==<br />
<br />
The current globally enabled hardening flags:<br />
<br />
* CPPFLAGS: -D_FORTIFY_SOURCE=2<br />
* CFLAGS/CXXFLAGS: -fstack-protector-strong<br />
* LDFLAGS: -Wl,-z,relro<br />
<br />
=== Packages not respecting flags ===<br />
<br />
==== Tangible attack surface ====<br />
<br />
* {{pkg|john}} - {{bug|43232}}<br />
* <s>{{pkg|gpsd}} - {{bug|43233}}</s><br />
* {{pkg|bzip2}} - {{bug|43231}}<br />
* {{pkg|festival}} - {{bug|43229}}<br />
* <s>{{pkg|zita-alsa-pcmi}} - {{bug|43230}}</s> - rebuild<br />
* <s>{{pkg|zita-resampler}}</s> - rebuild<br />
* <s>{{pkg|mpv}} - {{bug|43235}}</s> - hardening-wrapper<br />
* <s>{{pkg|ffmpeg}}</s> - hardening-wrapper<br />
* {{pkg|ghostscript}} - {{bug|43234}}<br />
* {{pkg|zip}} - {{bug|43236}}<br />
* <s>{{pkg|unrar}} - {{bug|43237}}</s> - hardening-wrapper<br />
* {{pkg|python}}, {{pkg|python2}} - {{bug|43246}}<br />
* {{pkg|imagemagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
* {{pkg|graphicsmagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
<br />
==== Seemingly no tangible attack surface ====<br />
<br />
{{Note|It would be nice if these were fixed but it doesn't seem worth filing bugs for them.}}<br />
<br />
* {{pkg|dmidecode}}<br />
* {{pkg|boost}}<br />
* {{pkg|gcc}}<br />
* {{pkg|libcap}}<br />
* {{pkg|glew}}<br />
* {{pkg|dmenu}}<br />
* {{pkg|gsl}}<br />
* {{pkg|hdparm}}<br />
* {{pkg|lm_sensors}}<br />
* {{pkg|lsof}}<br />
* {{pkg|procinfo-ng}}<br />
* {{pkg|nethogs}}<br />
* {{AUR|qtchooser}}<br />
* {{pkg|rust}}<br />
<br />
=== Full RELRO ===<br />
<br />
Arch passes {{ic|-z relro}} to the linker in the default {{ic|LDFLAGS}}, causing many internal ELF data sections to be marked read-only. However, passing {{ic|-z now}} to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|chromium}}<br />
* {{pkg|colord}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
=== PIE ===<br />
<br />
[[Wikipedia:ASLR|ASLR]] is enabled by default, and a stronger implementation is available in {{pkg|linux-grsec}}{{Broken package link|{{aur-mirror|linux-grsec}}}}. Data and code addresses in dynamic libraries are always randomized because these are always [[Wikipedia:Position independent code|position independent code]]. However, executables are not position independent by default and cannot take advantage of ASLR. This also applies to important ELF data like the GOT/PLT where many library functions will be referenced, so ASLR is essentially useless without PIE. Passing {{ic|-fPIE}} (or {{ic|-fPIC}}) while compiling and {{ic|-pie}} while linking will enable PIE, but these cannot simply be default flags because it will break libraries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|colord}}<br />
* {{pkg|chromium}}<br />
* {{pkg|cups}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|sudo}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
==== Example ====<br />
<br />
{{hc|aslr.c|<nowiki>#include <stdio.h><br />
<br />
static void foo() {}<br />
static int bar = 5;<br />
<br />
int main(void) {<br />
int baz = 5;<br />
printf("function: %p, library function: %p, data: %p, stack: %p\n", foo, &printf, &bar, &baz);<br />
return 0;<br />
}</nowiki>}}<br />
<br />
{{hc|$ gcc -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff909cac1c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffee85453c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0d05a1ec<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff6e250bbc<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff4889ec7c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0eb22b5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffdce51a0c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff8c42db5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffce276c2c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffedbb9ffc<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400516, library function: 0x7f1e55a3e150, data: 0x6009c0, stack: 0x7fff7ce9317c<br />
function: 0x400516, library function: 0x7ffae3294150, data: 0x6009c0, stack: 0x7fff428a8e1c<br />
function: 0x400516, library function: 0x7f39c4ed6150, data: 0x6009c0, stack: 0x7fffdb57db5c<br />
function: 0x400516, library function: 0x7f8e4fccd150, data: 0x6009c0, stack: 0x7ffffd46bd3c<br />
function: 0x400516, library function: 0x7f885508b150, data: 0x6009c0, stack: 0x7fffe7bf69cc<br />
function: 0x400516, library function: 0x7ffa9a05f150, data: 0x6009c0, stack: 0x7ffff89fdfac<br />
function: 0x400516, library function: 0x7ffe6114d150, data: 0x6009c0, stack: 0x7fff888accdc<br />
function: 0x400516, library function: 0x7f30f1893150, data: 0x6009c0, stack: 0x7fff2cfcb6bc<br />
function: 0x400516, library function: 0x7fd9e91dc150, data: 0x6009c0, stack: 0x7fff91c0062c<br />
function: 0x400516, library function: 0x7fdf4c136150, data: 0x6009c0, stack: 0x7fff7f96928c<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -pie -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x7f35659b4770, library function: 0x7f3565433150, data: 0x7f3565bb4c38, stack: 0x7ffff3de9a4c<br />
function: 0x7f173ab2b770, library function: 0x7f173a5aa150, data: 0x7f173ad2bc38, stack: 0x7fffa0e7b12c<br />
function: 0x7ff59b960770, library function: 0x7ff59b3df150, data: 0x7ff59bb60c38, stack: 0x7fffaca2f8cc<br />
function: 0x7f557c39e770, library function: 0x7f557be1d150, data: 0x7f557c59ec38, stack: 0x7fff9127b98c<br />
function: 0x7f1bc8f53770, library function: 0x7f1bc89d2150, data: 0x7f1bc9153c38, stack: 0x7fff75d767ac<br />
function: 0x7f8af81e8770, library function: 0x7f8af7c67150, data: 0x7f8af83e8c38, stack: 0x7fff4bb7856c<br />
function: 0x7f8be8334770, library function: 0x7f8be7db3150, data: 0x7f8be8534c38, stack: 0x7fffcf8b33cc<br />
function: 0x7f3c246a5770, library function: 0x7f3c24124150, data: 0x7f3c248a5c38, stack: 0x7fffb25d8ccc<br />
function: 0x7fa457c39770, library function: 0x7fa4576b8150, data: 0x7fa457e39c38, stack: 0x7fffc92d85fc<br />
function: 0x7f1dffbb8770, library function: 0x7f1dff637150, data: 0x7f1dffdb8c38, stack: 0x7fffd2bfff2c}}<br />
<br />
=== hardening-wrapper ===<br />
<br />
The {{pkg|hardening-wrapper}} package wraps C and C++ compilers in order to enable the chosen hardening flags by default for all builds. A wrapper (or patched toolchain) is a hard requirement for enabling PIE for all packages, because different flags need to be passed depending on whether an executable or library is being compiled. Enabling PIE by default on x86_64 should be pursued, and this is likely the best way to do it.<br />
<br />
== non-root X ==<br />
<br />
The {{pkg|xorg-server}} package now ships with {{ic|/usr/bin/Xorg}} as a wrapper script, calling the {{ic|/usr/bin/Xorg.wrap}} setuid binary and dropping privileges if possible (video driver with [[KMS]]). To decrease the attack surface, the setuid should be split into a separate package and added as a dependency to drivers without rootless X support. The script is already set up to fall back to {{ic|/usr/bin/Xorg.bin}} if the wrapper is unavailable.<br />
<br />
{{bug|41257}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Security&diff=476147DeveloperWiki:Security2017-05-07T18:09:21Z<p>Thestinger: /* World-readable/writeable directories */ fix</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
This page documents progress on fixing/implementing non-CVE security-related bugs and features.<br />
<br />
== Service Isolation ==<br />
<br />
Green cells indicate a security feature is implemented, and red cells indicate the lack of a feature. If it's not possible to implement a feature without losing functionality (even if off-by-default), a reason is given instead. This also applies to features that are simply not useful, such as PrivateTmp for services without any usage of {{ic|/tmp}} as these can be handled with InaccessibleDirectories.<br />
<br />
A red cell without a link to an issue report indicates that research/testing is required in order to either mark it as not possible or report an issue. <br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Package !! Service !! User !! Group !! PrivateDevices !! PrivateNetwork !! PrivateTmp<br />
|-<br />
| {{pkg|chrony}} || {{ic|chrony.service}} || {{G|chrony}} || {{G|chrony}} || can use {{ic|/dev/rtc}} || n/a || {{no}}<br />
|-<br />
| {{pkg|cronie}} || {{ic|cronie.service}} || root (jobs) || root (jobs) || jobs || jobs || jobs<br />
|-<br />
| {{pkg|lighttpd}} || {{ic|lighttpd.service}} || {{G|http}} || {{G|http}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|paxd}}{{Broken package link|package not found}} || {{ic|paxd.service}} || root (xattrs) || root (xattrs) || {{no}} || {{no}} || not used <br />
|-<br />
| {{pkg|pdnsd}} || {{ic|pdnsd.service}} || {{G|pdnsd}} || {{G|pdnsd}} || can use {{ic|/dev/isdninfo}} || n/a || not used <br />
|-<br />
| {{pkg|polipo}} || {{ic|polipo.service}} || {{G|polipo}} || {{G|polipo}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|polkit}} || {{ic|polkit.service}} || {{G|polkitd}} || {{G|polkitd}} || rules || rules || rules<br />
|-<br />
| {{pkg|privoxy}} || {{ic|privoxy.service}} || {{G|privoxy}} || {{G|privoxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|networkmanager}} || {{ic|NetworkManager.service}} || {{R|root}} || {{R|root}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|nginx}} || {{ic|nginx.service}} || {{G|http}} || {{G|http}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| rowspan=2 | {{pkg|ntp}} || {{ic|ntpdate.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{ic|ntpd.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|tor}} || {{ic|tor.service}} || {{G|tor}} || {{G|tor}} || {{yes}} || n/a || not used<br />
|-<br />
| {{pkg|tinyproxy}} || {{ic|tinyproxy.service}} || {{G|tinyproxy}} || {{G|tinyproxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|transmission-cli}} || {{ic|transmission.service}} || {{G|transmission}} || {{G|transmission}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|wpa_supplicant}} || {{ic|wpa_supplicant.service}} || {{R|root}} || {{R|root}} || {{no}} || {{no}} || {{no}}<br />
|-<br />
| {{pkg|znc}} || {{ic|znc.service}} || {{G|znc}} || {{G|znc}} || {{no}} || n/a || {{no}}<br />
|-<br />
|}<br />
<br />
=== User/Group ===<br />
<br />
In nearly every case, services should use an unprivileged user rather than running as root. Some cases may require the use of capabilities like CAP_NET_ADMIN or CAP_NET_BIND_SERVICE. Some exceptions are cron daemons, since they need to run scripts as root and anything needing CAP_SYS_ADMIN or a similar capability essentially equivalent to root access.<br />
<br />
It is '''not''' appropriate to run services as {{ic|nobody}}. If this user is shared among more than one service, then they are vulnerable to each other. For example, consider a caching dns server (pdnsd) running as nobody alongside ntpd running as nobody. If ntpd is compromised via a vulnerability, all the attacker should be able to do is mess with the time. However, thanks to the use of {{ic|nobody}} they will be able to intercept/modify all dns requests and alter the persistent cache.<br />
<br />
=== PrivateDevices ===<br />
<br />
If there is absolutely no usage of {{ic|/dev/}}, then {{ic|InaccessibleDirectories}} combined with {{ic|1=DevicePolicy=strict}} is a valid alternative.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateNetwork ===<br />
<br />
This can be used for any service without a need for network communication beyond sockets provided through socket activation.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateTmp ===<br />
<br />
This should only be used if a service needs to make use of {{ic|/tmp}}. Bash makes extensive use of {{ic|/tmp}} for stuff like here documents, so any shell usage is enough to make it worthwhile.<br />
<br />
https://fedoraproject.org/wiki/Features/ServicesPrivateTmp<br />
<br />
=== ReadOnly/ReadWrite ===<br />
<br />
systemd has some basic MAC capabilities (InaccessibleDirectories, ReadWriteDirectories, ReadOnlyDirectories), but is limited to directories since it's based on bind mounts in a mount namespace. These features do not currently have the ability to recurse into submounts, causing the increase in security to be misleading. It doesn't appear that a whitelist model will work yet either, so it's far from providing true isolation at this point.<br />
<br />
=== NetworkManager / wpa_supplicant ===<br />
<br />
It might be possible to drop nearly all capabilities other than CAP_NET_ADMIN. Of course, if these need CAP_SYS_ADMIN for something there's no point.<br />
<br />
== Replacing setuid with capabilities ==<br />
<br />
This is a scratch space tracking which packages still include setuid binaries and replacing these with capabilities where possible. Reducing setuid to CAP_SYS_ADMIN or any capabilities allowing escalation to root access is not very useful (at least without MAC/RBAC backing it up), so it will not be covered (yet?).<br />
<br />
* <s>{{Bug|39686}} - [inetutils] rsh, rcp and rlogin should use cap_net_bind_service, not setuid</s><br />
* {{pkg|sudo}} - requires setuid<br />
<br />
== kernel hardening ==<br />
<br />
* CONFIG_SECURITY_DMESG_RESTRICT ({{bug|39685}} - closed, not implemented)<br />
* kptr_restrict=1 ({{bug|34323}} - closed, not implemented)<br />
* CONFIG_RANDOMIZE_BASE ({{bug|41463}} - closed, not implemented)<br />
* higher CONFIG_DEFAULT_MMAP_MIN_ADDR ({{bug|41260}} - implemented)<br />
* RO/NX protections for loadable kernel modules ({{bug|41347}} - implemented)<br />
<br />
== Compiler / linker hardening ==<br />
<br />
The current globally enabled hardening flags:<br />
<br />
* CPPFLAGS: -D_FORTIFY_SOURCE=2<br />
* CFLAGS/CXXFLAGS: -fstack-protector-strong<br />
* LDFLAGS: -Wl,-z,relro<br />
<br />
=== Packages not respecting flags ===<br />
<br />
==== Tangible attack surface ====<br />
<br />
* {{pkg|john}} - {{bug|43232}}<br />
* <s>{{pkg|gpsd}} - {{bug|43233}}</s><br />
* {{pkg|bzip2}} - {{bug|43231}}<br />
* {{pkg|festival}} - {{bug|43229}}<br />
* <s>{{pkg|zita-alsa-pcmi}} - {{bug|43230}}</s> - rebuild<br />
* <s>{{pkg|zita-resampler}}</s> - rebuild<br />
* <s>{{pkg|mpv}} - {{bug|43235}}</s> - hardening-wrapper<br />
* <s>{{pkg|ffmpeg}}</s> - hardening-wrapper<br />
* {{pkg|ghostscript}} - {{bug|43234}}<br />
* {{pkg|zip}} - {{bug|43236}}<br />
* <s>{{pkg|unrar}} - {{bug|43237}}</s> - hardening-wrapper<br />
* {{pkg|python}}, {{pkg|python2}} - {{bug|43246}}<br />
* {{pkg|imagemagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
* {{pkg|graphicsmagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
<br />
==== Seemingly no tangible attack surface ====<br />
<br />
{{Note|It would be nice if these were fixed but it doesn't seem worth filing bugs for them.}}<br />
<br />
* {{pkg|dmidecode}}<br />
* {{pkg|boost}}<br />
* {{pkg|gcc}}<br />
* {{pkg|libcap}}<br />
* {{pkg|glew}}<br />
* {{pkg|dmenu}}<br />
* {{pkg|gsl}}<br />
* {{pkg|hdparm}}<br />
* {{pkg|lm_sensors}}<br />
* {{pkg|lsof}}<br />
* {{pkg|procinfo-ng}}<br />
* {{pkg|nethogs}}<br />
* {{AUR|qtchooser}}<br />
* {{pkg|rust}}<br />
<br />
=== Full RELRO ===<br />
<br />
Arch passes {{ic|-z relro}} to the linker in the default {{ic|LDFLAGS}}, causing many internal ELF data sections to be marked read-only. However, passing {{ic|-z now}} to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|chromium}}<br />
* {{pkg|colord}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
=== PIE ===<br />
<br />
[[Wikipedia:ASLR|ASLR]] is enabled by default, and a stronger implementation is available in {{pkg|linux-grsec}}{{Broken package link|{{aur-mirror|linux-grsec}}}}. Data and code addresses in dynamic libraries are always randomized because these are always [[Wikipedia:Position independent code|position independent code]]. However, executables are not position independent by default and cannot take advantage of ASLR. This also applies to important ELF data like the GOT/PLT where many library functions will be referenced, so ASLR is essentially useless without PIE. Passing {{ic|-fPIE}} (or {{ic|-fPIC}}) while compiling and {{ic|-pie}} while linking will enable PIE, but these cannot simply be default flags because it will break libraries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|colord}}<br />
* {{pkg|chromium}}<br />
* {{pkg|cups}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|sudo}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
==== Example ====<br />
<br />
{{hc|aslr.c|<nowiki>#include <stdio.h><br />
<br />
static void foo() {}<br />
static int bar = 5;<br />
<br />
int main(void) {<br />
int baz = 5;<br />
printf("function: %p, library function: %p, data: %p, stack: %p\n", foo, &printf, &bar, &baz);<br />
return 0;<br />
}</nowiki>}}<br />
<br />
{{hc|$ gcc -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff909cac1c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffee85453c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0d05a1ec<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff6e250bbc<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff4889ec7c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0eb22b5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffdce51a0c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff8c42db5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffce276c2c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffedbb9ffc<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400516, library function: 0x7f1e55a3e150, data: 0x6009c0, stack: 0x7fff7ce9317c<br />
function: 0x400516, library function: 0x7ffae3294150, data: 0x6009c0, stack: 0x7fff428a8e1c<br />
function: 0x400516, library function: 0x7f39c4ed6150, data: 0x6009c0, stack: 0x7fffdb57db5c<br />
function: 0x400516, library function: 0x7f8e4fccd150, data: 0x6009c0, stack: 0x7ffffd46bd3c<br />
function: 0x400516, library function: 0x7f885508b150, data: 0x6009c0, stack: 0x7fffe7bf69cc<br />
function: 0x400516, library function: 0x7ffa9a05f150, data: 0x6009c0, stack: 0x7ffff89fdfac<br />
function: 0x400516, library function: 0x7ffe6114d150, data: 0x6009c0, stack: 0x7fff888accdc<br />
function: 0x400516, library function: 0x7f30f1893150, data: 0x6009c0, stack: 0x7fff2cfcb6bc<br />
function: 0x400516, library function: 0x7fd9e91dc150, data: 0x6009c0, stack: 0x7fff91c0062c<br />
function: 0x400516, library function: 0x7fdf4c136150, data: 0x6009c0, stack: 0x7fff7f96928c<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -pie -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x7f35659b4770, library function: 0x7f3565433150, data: 0x7f3565bb4c38, stack: 0x7ffff3de9a4c<br />
function: 0x7f173ab2b770, library function: 0x7f173a5aa150, data: 0x7f173ad2bc38, stack: 0x7fffa0e7b12c<br />
function: 0x7ff59b960770, library function: 0x7ff59b3df150, data: 0x7ff59bb60c38, stack: 0x7fffaca2f8cc<br />
function: 0x7f557c39e770, library function: 0x7f557be1d150, data: 0x7f557c59ec38, stack: 0x7fff9127b98c<br />
function: 0x7f1bc8f53770, library function: 0x7f1bc89d2150, data: 0x7f1bc9153c38, stack: 0x7fff75d767ac<br />
function: 0x7f8af81e8770, library function: 0x7f8af7c67150, data: 0x7f8af83e8c38, stack: 0x7fff4bb7856c<br />
function: 0x7f8be8334770, library function: 0x7f8be7db3150, data: 0x7f8be8534c38, stack: 0x7fffcf8b33cc<br />
function: 0x7f3c246a5770, library function: 0x7f3c24124150, data: 0x7f3c248a5c38, stack: 0x7fffb25d8ccc<br />
function: 0x7fa457c39770, library function: 0x7fa4576b8150, data: 0x7fa457e39c38, stack: 0x7fffc92d85fc<br />
function: 0x7f1dffbb8770, library function: 0x7f1dff637150, data: 0x7f1dffdb8c38, stack: 0x7fffd2bfff2c}}<br />
<br />
=== hardening-wrapper ===<br />
<br />
The {{pkg|hardening-wrapper}} package wraps C and C++ compilers in order to enable the chosen hardening flags by default for all builds. A wrapper (or patched toolchain) is a hard requirement for enabling PIE for all packages, because different flags need to be passed depending on whether an executable or library is being compiled. Enabling PIE by default on x86_64 should be pursued, and this is likely the best way to do it.<br />
<br />
== non-root X ==<br />
<br />
The {{pkg|xorg-server}} package now ships with {{ic|/usr/bin/Xorg}} as a wrapper script, calling the {{ic|/usr/bin/Xorg.wrap}} setuid binary and dropping privileges if possible (video driver with [[KMS]]). To decrease the attack surface, the setuid should be split into a separate package and added as a dependency to drivers without rootless X support. The script is already set up to fall back to {{ic|/usr/bin/Xorg.bin}} if the wrapper is unavailable.<br />
<br />
{{bug|41257}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Security&diff=476146DeveloperWiki:Security2017-05-07T18:08:41Z<p>Thestinger: /* Compiler / linker hardening */ update</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
This page documents progress on fixing/implementing non-CVE security-related bugs and features.<br />
<br />
== Service Isolation ==<br />
<br />
Green cells indicate a security feature is implemented, and red cells indicate the lack of a feature. If it's not possible to implement a feature without losing functionality (even if off-by-default), a reason is given instead. This also applies to features that are simply not useful, such as PrivateTmp for services without any usage of {{ic|/tmp}} as these can be handled with InaccessibleDirectories.<br />
<br />
A red cell without a link to an issue report indicates that research/testing is required in order to either mark it as not possible or report an issue. <br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Package !! Service !! User !! Group !! PrivateDevices !! PrivateNetwork !! PrivateTmp<br />
|-<br />
| {{pkg|chrony}} || {{ic|chrony.service}} || {{G|chrony}} || {{G|chrony}} || can use {{ic|/dev/rtc}} || n/a || {{no}}<br />
|-<br />
| {{pkg|cronie}} || {{ic|cronie.service}} || root (jobs) || root (jobs) || jobs || jobs || jobs<br />
|-<br />
| {{pkg|lighttpd}} || {{ic|lighttpd.service}} || {{G|http}} || {{G|http}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|paxd}}{{Broken package link|package not found}} || {{ic|paxd.service}} || root (xattrs) || root (xattrs) || {{no}} || {{no}} || not used <br />
|-<br />
| {{pkg|pdnsd}} || {{ic|pdnsd.service}} || {{G|pdnsd}} || {{G|pdnsd}} || can use {{ic|/dev/isdninfo}} || n/a || not used <br />
|-<br />
| {{pkg|polipo}} || {{ic|polipo.service}} || {{G|polipo}} || {{G|polipo}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|polkit}} || {{ic|polkit.service}} || {{G|polkitd}} || {{G|polkitd}} || rules || rules || rules<br />
|-<br />
| {{pkg|privoxy}} || {{ic|privoxy.service}} || {{G|privoxy}} || {{G|privoxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|networkmanager}} || {{ic|NetworkManager.service}} || {{R|root}} || {{R|root}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|nginx}} || {{ic|nginx.service}} || {{G|http}} || {{G|http}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| rowspan=2 | {{pkg|ntp}} || {{ic|ntpdate.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{ic|ntpd.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|tor}} || {{ic|tor.service}} || {{G|tor}} || {{G|tor}} || {{yes}} || n/a || not used<br />
|-<br />
| {{pkg|tinyproxy}} || {{ic|tinyproxy.service}} || {{G|tinyproxy}} || {{G|tinyproxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|transmission-cli}} || {{ic|transmission.service}} || {{G|transmission}} || {{G|transmission}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|wpa_supplicant}} || {{ic|wpa_supplicant.service}} || {{R|root}} || {{R|root}} || {{no}} || {{no}} || {{no}}<br />
|-<br />
| {{pkg|znc}} || {{ic|znc.service}} || {{G|znc}} || {{G|znc}} || {{no}} || n/a || {{no}}<br />
|-<br />
|}<br />
<br />
=== User/Group ===<br />
<br />
In nearly every case, services should use an unprivileged user rather than running as root. Some cases may require the use of capabilities like CAP_NET_ADMIN or CAP_NET_BIND_SERVICE. Some exceptions are cron daemons, since they need to run scripts as root and anything needing CAP_SYS_ADMIN or a similar capability essentially equivalent to root access.<br />
<br />
It is '''not''' appropriate to run services as {{ic|nobody}}. If this user is shared among more than one service, then they are vulnerable to each other. For example, consider a caching dns server (pdnsd) running as nobody alongside ntpd running as nobody. If ntpd is compromised via a vulnerability, all the attacker should be able to do is mess with the time. However, thanks to the use of {{ic|nobody}} they will be able to intercept/modify all dns requests and alter the persistent cache.<br />
<br />
=== PrivateDevices ===<br />
<br />
If there is absolutely no usage of {{ic|/dev/}}, then {{ic|InaccessibleDirectories}} combined with {{ic|1=DevicePolicy=strict}} is a valid alternative.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateNetwork ===<br />
<br />
This can be used for any service without a need for network communication beyond sockets provided through socket activation.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateTmp ===<br />
<br />
This should only be used if a service needs to make use of {{ic|/tmp}}. Bash makes extensive use of {{ic|/tmp}} for stuff like here documents, so any shell usage is enough to make it worthwhile.<br />
<br />
https://fedoraproject.org/wiki/Features/ServicesPrivateTmp<br />
<br />
=== ReadOnly/ReadWrite ===<br />
<br />
systemd has some basic MAC capabilities (InaccessibleDirectories, ReadWriteDirectories, ReadOnlyDirectories), but is limited to directories since it's based on bind mounts in a mount namespace. These features do not currently have the ability to recurse into submounts, causing the increase in security to be misleading. It doesn't appear that a whitelist model will work yet either, so it's far from providing true isolation at this point.<br />
<br />
=== NetworkManager / wpa_supplicant ===<br />
<br />
It might be possible to drop nearly all capabilities other than CAP_NET_ADMIN. Of course, if these need CAP_SYS_ADMIN for something there's no point.<br />
<br />
== World-readable/writeable directories ==<br />
<br />
Many packages have unnecessarily world-readable directories, and some even have unnecessarily world-writeable ones. These permissions should be tightened up.<br />
<br />
* {{bug|39808}} - [lighttpd] /var/{cache,log}/lighttpd should not be world-readable<br />
<br />
== Replacing setuid with capabilities ==<br />
<br />
This is a scratch space tracking which packages still include setuid binaries and replacing these with capabilities where possible. Reducing setuid to CAP_SYS_ADMIN or any capabilities allowing escalation to root access is not very useful (at least without MAC/RBAC backing it up), so it will not be covered (yet?).<br />
<br />
* <s>{{Bug|39686}} - [inetutils] rsh, rcp and rlogin should use cap_net_bind_service, not setuid</s><br />
* {{pkg|sudo}} - requires setuid<br />
<br />
== kernel hardening ==<br />
<br />
* CONFIG_SECURITY_DMESG_RESTRICT ({{bug|39685}} - closed, not implemented)<br />
* kptr_restrict=1 ({{bug|34323}} - closed, not implemented)<br />
* CONFIG_RANDOMIZE_BASE ({{bug|41463}} - closed, not implemented)<br />
* higher CONFIG_DEFAULT_MMAP_MIN_ADDR ({{bug|41260}} - implemented)<br />
* RO/NX protections for loadable kernel modules ({{bug|41347}} - implemented)<br />
<br />
== Compiler / linker hardening ==<br />
<br />
The current globally enabled hardening flags:<br />
<br />
* CPPFLAGS: -D_FORTIFY_SOURCE=2<br />
* CFLAGS/CXXFLAGS: -fstack-protector-strong<br />
* LDFLAGS: -Wl,-z,relro<br />
<br />
=== Packages not respecting flags ===<br />
<br />
==== Tangible attack surface ====<br />
<br />
* {{pkg|john}} - {{bug|43232}}<br />
* <s>{{pkg|gpsd}} - {{bug|43233}}</s><br />
* {{pkg|bzip2}} - {{bug|43231}}<br />
* {{pkg|festival}} - {{bug|43229}}<br />
* <s>{{pkg|zita-alsa-pcmi}} - {{bug|43230}}</s> - rebuild<br />
* <s>{{pkg|zita-resampler}}</s> - rebuild<br />
* <s>{{pkg|mpv}} - {{bug|43235}}</s> - hardening-wrapper<br />
* <s>{{pkg|ffmpeg}}</s> - hardening-wrapper<br />
* {{pkg|ghostscript}} - {{bug|43234}}<br />
* {{pkg|zip}} - {{bug|43236}}<br />
* <s>{{pkg|unrar}} - {{bug|43237}}</s> - hardening-wrapper<br />
* {{pkg|python}}, {{pkg|python2}} - {{bug|43246}}<br />
* {{pkg|imagemagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
* {{pkg|graphicsmagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
<br />
==== Seemingly no tangible attack surface ====<br />
<br />
{{Note|It would be nice if these were fixed but it doesn't seem worth filing bugs for them.}}<br />
<br />
* {{pkg|dmidecode}}<br />
* {{pkg|boost}}<br />
* {{pkg|gcc}}<br />
* {{pkg|libcap}}<br />
* {{pkg|glew}}<br />
* {{pkg|dmenu}}<br />
* {{pkg|gsl}}<br />
* {{pkg|hdparm}}<br />
* {{pkg|lm_sensors}}<br />
* {{pkg|lsof}}<br />
* {{pkg|procinfo-ng}}<br />
* {{pkg|nethogs}}<br />
* {{AUR|qtchooser}}<br />
* {{pkg|rust}}<br />
<br />
=== Full RELRO ===<br />
<br />
Arch passes {{ic|-z relro}} to the linker in the default {{ic|LDFLAGS}}, causing many internal ELF data sections to be marked read-only. However, passing {{ic|-z now}} to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|chromium}}<br />
* {{pkg|colord}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
=== PIE ===<br />
<br />
[[Wikipedia:ASLR|ASLR]] is enabled by default, and a stronger implementation is available in {{pkg|linux-grsec}}{{Broken package link|{{aur-mirror|linux-grsec}}}}. Data and code addresses in dynamic libraries are always randomized because these are always [[Wikipedia:Position independent code|position independent code]]. However, executables are not position independent by default and cannot take advantage of ASLR. This also applies to important ELF data like the GOT/PLT where many library functions will be referenced, so ASLR is essentially useless without PIE. Passing {{ic|-fPIE}} (or {{ic|-fPIC}}) while compiling and {{ic|-pie}} while linking will enable PIE, but these cannot simply be default flags because it will break libraries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|colord}}<br />
* {{pkg|chromium}}<br />
* {{pkg|cups}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|sudo}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
==== Example ====<br />
<br />
{{hc|aslr.c|<nowiki>#include <stdio.h><br />
<br />
static void foo() {}<br />
static int bar = 5;<br />
<br />
int main(void) {<br />
int baz = 5;<br />
printf("function: %p, library function: %p, data: %p, stack: %p\n", foo, &printf, &bar, &baz);<br />
return 0;<br />
}</nowiki>}}<br />
<br />
{{hc|$ gcc -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff909cac1c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffee85453c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0d05a1ec<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff6e250bbc<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff4889ec7c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0eb22b5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffdce51a0c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff8c42db5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffce276c2c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffedbb9ffc<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400516, library function: 0x7f1e55a3e150, data: 0x6009c0, stack: 0x7fff7ce9317c<br />
function: 0x400516, library function: 0x7ffae3294150, data: 0x6009c0, stack: 0x7fff428a8e1c<br />
function: 0x400516, library function: 0x7f39c4ed6150, data: 0x6009c0, stack: 0x7fffdb57db5c<br />
function: 0x400516, library function: 0x7f8e4fccd150, data: 0x6009c0, stack: 0x7ffffd46bd3c<br />
function: 0x400516, library function: 0x7f885508b150, data: 0x6009c0, stack: 0x7fffe7bf69cc<br />
function: 0x400516, library function: 0x7ffa9a05f150, data: 0x6009c0, stack: 0x7ffff89fdfac<br />
function: 0x400516, library function: 0x7ffe6114d150, data: 0x6009c0, stack: 0x7fff888accdc<br />
function: 0x400516, library function: 0x7f30f1893150, data: 0x6009c0, stack: 0x7fff2cfcb6bc<br />
function: 0x400516, library function: 0x7fd9e91dc150, data: 0x6009c0, stack: 0x7fff91c0062c<br />
function: 0x400516, library function: 0x7fdf4c136150, data: 0x6009c0, stack: 0x7fff7f96928c<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -pie -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x7f35659b4770, library function: 0x7f3565433150, data: 0x7f3565bb4c38, stack: 0x7ffff3de9a4c<br />
function: 0x7f173ab2b770, library function: 0x7f173a5aa150, data: 0x7f173ad2bc38, stack: 0x7fffa0e7b12c<br />
function: 0x7ff59b960770, library function: 0x7ff59b3df150, data: 0x7ff59bb60c38, stack: 0x7fffaca2f8cc<br />
function: 0x7f557c39e770, library function: 0x7f557be1d150, data: 0x7f557c59ec38, stack: 0x7fff9127b98c<br />
function: 0x7f1bc8f53770, library function: 0x7f1bc89d2150, data: 0x7f1bc9153c38, stack: 0x7fff75d767ac<br />
function: 0x7f8af81e8770, library function: 0x7f8af7c67150, data: 0x7f8af83e8c38, stack: 0x7fff4bb7856c<br />
function: 0x7f8be8334770, library function: 0x7f8be7db3150, data: 0x7f8be8534c38, stack: 0x7fffcf8b33cc<br />
function: 0x7f3c246a5770, library function: 0x7f3c24124150, data: 0x7f3c248a5c38, stack: 0x7fffb25d8ccc<br />
function: 0x7fa457c39770, library function: 0x7fa4576b8150, data: 0x7fa457e39c38, stack: 0x7fffc92d85fc<br />
function: 0x7f1dffbb8770, library function: 0x7f1dff637150, data: 0x7f1dffdb8c38, stack: 0x7fffd2bfff2c}}<br />
<br />
=== hardening-wrapper ===<br />
<br />
The {{pkg|hardening-wrapper}} package wraps C and C++ compilers in order to enable the chosen hardening flags by default for all builds. A wrapper (or patched toolchain) is a hard requirement for enabling PIE for all packages, because different flags need to be passed depending on whether an executable or library is being compiled. Enabling PIE by default on x86_64 should be pursued, and this is likely the best way to do it.<br />
<br />
== non-root X ==<br />
<br />
The {{pkg|xorg-server}} package now ships with {{ic|/usr/bin/Xorg}} as a wrapper script, calling the {{ic|/usr/bin/Xorg.wrap}} setuid binary and dropping privileges if possible (video driver with [[KMS]]). To decrease the attack surface, the setuid should be split into a separate package and added as a dependency to drivers without rootless X support. The script is already set up to fall back to {{ic|/usr/bin/Xorg.bin}} if the wrapper is unavailable.<br />
<br />
{{bug|41257}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Security&diff=476145DeveloperWiki:Security2017-05-07T18:07:51Z<p>Thestinger: /* grsecurity */ gone</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
This page documents progress on fixing/implementing non-CVE security-related bugs and features.<br />
<br />
== Service Isolation ==<br />
<br />
Green cells indicate a security feature is implemented, and red cells indicate the lack of a feature. If it's not possible to implement a feature without losing functionality (even if off-by-default), a reason is given instead. This also applies to features that are simply not useful, such as PrivateTmp for services without any usage of {{ic|/tmp}} as these can be handled with InaccessibleDirectories.<br />
<br />
A red cell without a link to an issue report indicates that research/testing is required in order to either mark it as not possible or report an issue. <br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Package !! Service !! User !! Group !! PrivateDevices !! PrivateNetwork !! PrivateTmp<br />
|-<br />
| {{pkg|chrony}} || {{ic|chrony.service}} || {{G|chrony}} || {{G|chrony}} || can use {{ic|/dev/rtc}} || n/a || {{no}}<br />
|-<br />
| {{pkg|cronie}} || {{ic|cronie.service}} || root (jobs) || root (jobs) || jobs || jobs || jobs<br />
|-<br />
| {{pkg|lighttpd}} || {{ic|lighttpd.service}} || {{G|http}} || {{G|http}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|paxd}}{{Broken package link|package not found}} || {{ic|paxd.service}} || root (xattrs) || root (xattrs) || {{no}} || {{no}} || not used <br />
|-<br />
| {{pkg|pdnsd}} || {{ic|pdnsd.service}} || {{G|pdnsd}} || {{G|pdnsd}} || can use {{ic|/dev/isdninfo}} || n/a || not used <br />
|-<br />
| {{pkg|polipo}} || {{ic|polipo.service}} || {{G|polipo}} || {{G|polipo}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|polkit}} || {{ic|polkit.service}} || {{G|polkitd}} || {{G|polkitd}} || rules || rules || rules<br />
|-<br />
| {{pkg|privoxy}} || {{ic|privoxy.service}} || {{G|privoxy}} || {{G|privoxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|networkmanager}} || {{ic|NetworkManager.service}} || {{R|root}} || {{R|root}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|nginx}} || {{ic|nginx.service}} || {{G|http}} || {{G|http}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| rowspan=2 | {{pkg|ntp}} || {{ic|ntpdate.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{ic|ntpd.service}} || {{G|ntp}} || {{G|ntp}} || {{no}} || n/a || {{yes}}<br />
|-<br />
| {{pkg|tor}} || {{ic|tor.service}} || {{G|tor}} || {{G|tor}} || {{yes}} || n/a || not used<br />
|-<br />
| {{pkg|tinyproxy}} || {{ic|tinyproxy.service}} || {{G|tinyproxy}} || {{G|tinyproxy}} || {{yes}} || n/a || {{no}}<br />
|-<br />
| {{pkg|transmission-cli}} || {{ic|transmission.service}} || {{G|transmission}} || {{G|transmission}} || {{no}} || n/a || {{no}}<br />
|-<br />
| {{pkg|wpa_supplicant}} || {{ic|wpa_supplicant.service}} || {{R|root}} || {{R|root}} || {{no}} || {{no}} || {{no}}<br />
|-<br />
| {{pkg|znc}} || {{ic|znc.service}} || {{G|znc}} || {{G|znc}} || {{no}} || n/a || {{no}}<br />
|-<br />
|}<br />
<br />
=== User/Group ===<br />
<br />
In nearly every case, services should use an unprivileged user rather than running as root. Some cases may require the use of capabilities like CAP_NET_ADMIN or CAP_NET_BIND_SERVICE. Some exceptions are cron daemons, since they need to run scripts as root and anything needing CAP_SYS_ADMIN or a similar capability essentially equivalent to root access.<br />
<br />
It is '''not''' appropriate to run services as {{ic|nobody}}. If this user is shared among more than one service, then they are vulnerable to each other. For example, consider a caching dns server (pdnsd) running as nobody alongside ntpd running as nobody. If ntpd is compromised via a vulnerability, all the attacker should be able to do is mess with the time. However, thanks to the use of {{ic|nobody}} they will be able to intercept/modify all dns requests and alter the persistent cache.<br />
<br />
=== PrivateDevices ===<br />
<br />
If there is absolutely no usage of {{ic|/dev/}}, then {{ic|InaccessibleDirectories}} combined with {{ic|1=DevicePolicy=strict}} is a valid alternative.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateNetwork ===<br />
<br />
This can be used for any service without a need for network communication beyond sockets provided through socket activation.<br />
<br />
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork<br />
<br />
=== PrivateTmp ===<br />
<br />
This should only be used if a service needs to make use of {{ic|/tmp}}. Bash makes extensive use of {{ic|/tmp}} for stuff like here documents, so any shell usage is enough to make it worthwhile.<br />
<br />
https://fedoraproject.org/wiki/Features/ServicesPrivateTmp<br />
<br />
=== ReadOnly/ReadWrite ===<br />
<br />
systemd has some basic MAC capabilities (InaccessibleDirectories, ReadWriteDirectories, ReadOnlyDirectories), but is limited to directories since it's based on bind mounts in a mount namespace. These features do not currently have the ability to recurse into submounts, causing the increase in security to be misleading. It doesn't appear that a whitelist model will work yet either, so it's far from providing true isolation at this point.<br />
<br />
=== NetworkManager / wpa_supplicant ===<br />
<br />
It might be possible to drop nearly all capabilities other than CAP_NET_ADMIN. Of course, if these need CAP_SYS_ADMIN for something there's no point.<br />
<br />
== World-readable/writeable directories ==<br />
<br />
Many packages have unnecessarily world-readable directories, and some even have unnecessarily world-writeable ones. These permissions should be tightened up.<br />
<br />
* {{bug|39808}} - [lighttpd] /var/{cache,log}/lighttpd should not be world-readable<br />
<br />
== Replacing setuid with capabilities ==<br />
<br />
This is a scratch space tracking which packages still include setuid binaries and replacing these with capabilities where possible. Reducing setuid to CAP_SYS_ADMIN or any capabilities allowing escalation to root access is not very useful (at least without MAC/RBAC backing it up), so it will not be covered (yet?).<br />
<br />
* <s>{{Bug|39686}} - [inetutils] rsh, rcp and rlogin should use cap_net_bind_service, not setuid</s><br />
* {{pkg|sudo}} - requires setuid<br />
<br />
== kernel hardening ==<br />
<br />
* CONFIG_SECURITY_DMESG_RESTRICT ({{bug|39685}} - closed, not implemented)<br />
* kptr_restrict=1 ({{bug|34323}} - closed, not implemented)<br />
* CONFIG_RANDOMIZE_BASE ({{bug|41463}} - closed, not implemented)<br />
* higher CONFIG_DEFAULT_MMAP_MIN_ADDR ({{bug|41260}} - implemented)<br />
* RO/NX protections for loadable kernel modules ({{bug|41347}} - implemented)<br />
<br />
== Compiler / linker hardening ==<br />
<br />
The current globally enabled hardening flags:<br />
<br />
* CPPFLAGS: -D_FORTIFY_SOURCE=2<br />
* CFLAGS/CXXFLAGS: -fstack-protector-strong --param=ssp-buffer-size=4<br />
* LDFLAGS: -z relro<br />
<br />
=== Packages not respecting flags ===<br />
<br />
==== Tangible attack surface ====<br />
<br />
* {{pkg|john}} - {{bug|43232}}<br />
* <s>{{pkg|gpsd}} - {{bug|43233}}</s><br />
* {{pkg|bzip2}} - {{bug|43231}}<br />
* {{pkg|festival}} - {{bug|43229}}<br />
* <s>{{pkg|zita-alsa-pcmi}} - {{bug|43230}}</s> - rebuild<br />
* <s>{{pkg|zita-resampler}}</s> - rebuild<br />
* <s>{{pkg|mpv}} - {{bug|43235}}</s> - hardening-wrapper<br />
* <s>{{pkg|ffmpeg}}</s> - hardening-wrapper<br />
* {{pkg|ghostscript}} - {{bug|43234}}<br />
* {{pkg|zip}} - {{bug|43236}}<br />
* <s>{{pkg|unrar}} - {{bug|43237}}</s> - hardening-wrapper<br />
* {{pkg|python}}, {{pkg|python2}} - {{bug|43246}}<br />
* {{pkg|imagemagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
* {{pkg|graphicsmagick}} - missing SSP even with hardening-wrapper, needs to be investigated<br />
<br />
==== Seemingly no tangible attack surface ====<br />
<br />
{{Note|It would be nice if these were fixed but it doesn't seem worth filing bugs for them.}}<br />
<br />
* {{pkg|dmidecode}}<br />
* {{pkg|boost}}<br />
* {{pkg|gcc}}<br />
* {{pkg|libcap}}<br />
* {{pkg|glew}}<br />
* {{pkg|dmenu}}<br />
* {{pkg|gsl}}<br />
* {{pkg|hdparm}}<br />
* {{pkg|lm_sensors}}<br />
* {{pkg|lsof}}<br />
* {{pkg|procinfo-ng}}<br />
* {{pkg|nethogs}}<br />
* {{AUR|qtchooser}}<br />
* {{pkg|rust}}<br />
<br />
=== Full RELRO ===<br />
<br />
Arch passes {{ic|-z relro}} to the linker in the default {{ic|LDFLAGS}}, causing many internal ELF data sections to be marked read-only. However, passing {{ic|-z now}} to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|chromium}}<br />
* {{pkg|colord}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
=== PIE ===<br />
<br />
[[Wikipedia:ASLR|ASLR]] is enabled by default, and a stronger implementation is available in {{pkg|linux-grsec}}{{Broken package link|{{aur-mirror|linux-grsec}}}}. Data and code addresses in dynamic libraries are always randomized because these are always [[Wikipedia:Position independent code|position independent code]]. However, executables are not position independent by default and cannot take advantage of ASLR. This also applies to important ELF data like the GOT/PLT where many library functions will be referenced, so ASLR is essentially useless without PIE. Passing {{ic|-fPIE}} (or {{ic|-fPIC}}) while compiling and {{ic|-pie}} while linking will enable PIE, but these cannot simply be default flags because it will break libraries.<br />
<br />
Packages with this enabled by default via upstream build flags:<br />
<br />
{{expansion|reason=This is likely far from a complete list.}}<br />
<br />
* {{pkg|colord}}<br />
* {{pkg|chromium}}<br />
* {{pkg|cups}}<br />
* {{pkg|playpen}}{{Broken package link|package not found}}<br />
* {{pkg|openssh}}<br />
* {{pkg|qemu}}<br />
* {{pkg|sudo}}<br />
* {{pkg|systemd}}<br />
* {{pkg|upower}}<br />
* {{pkg|tor}}<br />
<br />
==== Example ====<br />
<br />
{{hc|aslr.c|<nowiki>#include <stdio.h><br />
<br />
static void foo() {}<br />
static int bar = 5;<br />
<br />
int main(void) {<br />
int baz = 5;<br />
printf("function: %p, library function: %p, data: %p, stack: %p\n", foo, &printf, &bar, &baz);<br />
return 0;<br />
}</nowiki>}}<br />
<br />
{{hc|$ gcc -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff909cac1c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffee85453c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0d05a1ec<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff6e250bbc<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff4889ec7c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff0eb22b5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffdce51a0c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fff8c42db5c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffce276c2c<br />
function: 0x400506, library function: 0x4003e0, data: 0x600998, stack: 0x7fffedbb9ffc<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x400516, library function: 0x7f1e55a3e150, data: 0x6009c0, stack: 0x7fff7ce9317c<br />
function: 0x400516, library function: 0x7ffae3294150, data: 0x6009c0, stack: 0x7fff428a8e1c<br />
function: 0x400516, library function: 0x7f39c4ed6150, data: 0x6009c0, stack: 0x7fffdb57db5c<br />
function: 0x400516, library function: 0x7f8e4fccd150, data: 0x6009c0, stack: 0x7ffffd46bd3c<br />
function: 0x400516, library function: 0x7f885508b150, data: 0x6009c0, stack: 0x7fffe7bf69cc<br />
function: 0x400516, library function: 0x7ffa9a05f150, data: 0x6009c0, stack: 0x7ffff89fdfac<br />
function: 0x400516, library function: 0x7ffe6114d150, data: 0x6009c0, stack: 0x7fff888accdc<br />
function: 0x400516, library function: 0x7f30f1893150, data: 0x6009c0, stack: 0x7fff2cfcb6bc<br />
function: 0x400516, library function: 0x7fd9e91dc150, data: 0x6009c0, stack: 0x7fff91c0062c<br />
function: 0x400516, library function: 0x7fdf4c136150, data: 0x6009c0, stack: 0x7fff7f96928c<br />
}}<br />
<br />
{{hc|$ gcc -fPIE -pie -o aslr aslr.c; for i in $(seq 1 10); do ./aslr; done|<br />
function: 0x7f35659b4770, library function: 0x7f3565433150, data: 0x7f3565bb4c38, stack: 0x7ffff3de9a4c<br />
function: 0x7f173ab2b770, library function: 0x7f173a5aa150, data: 0x7f173ad2bc38, stack: 0x7fffa0e7b12c<br />
function: 0x7ff59b960770, library function: 0x7ff59b3df150, data: 0x7ff59bb60c38, stack: 0x7fffaca2f8cc<br />
function: 0x7f557c39e770, library function: 0x7f557be1d150, data: 0x7f557c59ec38, stack: 0x7fff9127b98c<br />
function: 0x7f1bc8f53770, library function: 0x7f1bc89d2150, data: 0x7f1bc9153c38, stack: 0x7fff75d767ac<br />
function: 0x7f8af81e8770, library function: 0x7f8af7c67150, data: 0x7f8af83e8c38, stack: 0x7fff4bb7856c<br />
function: 0x7f8be8334770, library function: 0x7f8be7db3150, data: 0x7f8be8534c38, stack: 0x7fffcf8b33cc<br />
function: 0x7f3c246a5770, library function: 0x7f3c24124150, data: 0x7f3c248a5c38, stack: 0x7fffb25d8ccc<br />
function: 0x7fa457c39770, library function: 0x7fa4576b8150, data: 0x7fa457e39c38, stack: 0x7fffc92d85fc<br />
function: 0x7f1dffbb8770, library function: 0x7f1dff637150, data: 0x7f1dffdb8c38, stack: 0x7fffd2bfff2c}}<br />
<br />
=== hardening-wrapper ===<br />
<br />
The {{pkg|hardening-wrapper}} package wraps C and C++ compilers in order to enable the chosen hardening flags by default for all builds. A wrapper (or patched toolchain) is a hard requirement for enabling PIE for all packages, because different flags need to be passed depending on whether an executable or library is being compiled. Enabling PIE by default on x86_64 should be pursued, and this is likely the best way to do it.<br />
<br />
== non-root X ==<br />
<br />
The {{pkg|xorg-server}} package now ships with {{ic|/usr/bin/Xorg}} as a wrapper script, calling the {{ic|/usr/bin/Xorg.wrap}} setuid binary and dropping privileges if possible (video driver with [[KMS]]). To decrease the attack surface, the setuid should be split into a separate package and added as a dependency to drivers without rootless X support. The script is already set up to fall back to {{ic|/usr/bin/Xorg.bin}} if the wrapper is unavailable.<br />
<br />
{{bug|41257}}</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476144Security2017-05-07T18:07:10Z<p>Thestinger: /* Examples of broken functionality */ using setcap like that is an extremely bad idea, you're better off disabling this feature</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Kernel&diff=476143Kernel2017-05-07T17:43:31Z<p>Thestinger: /* Precompiled kernels */ linux-hardened</p>
<hr />
<div>[[Category:Kernel]]<br />
[[cs:Kernel Compilation]]<br />
[[es:Kernels]]<br />
[[fr:Noyaux Linux]]<br />
[[it:Kernels]]<br />
[[ja:カーネル]]<br />
[[ru:Kernels]]<br />
[[zh-hans:Kernels]]<br />
{{Related articles start}}<br />
{{Related|Kernel modules}}<br />
{{Related|Compile kernel module}}<br />
{{Related|Kernel Panics}}<br />
{{Related|Linux-ck}}<br />
{{Related|sysctl}}<br />
{{Related articles end}}<br />
<br />
According to [[Wikipedia:Kernel (computing)|Wikipedia]]:<br />
:The kernel is a computer program that constitutes the central core of a computer's operating system. It has complete control over everything that occurs in the system. As such, it is the first program loaded on startup, and then manages the remainder of the startup, as well as input/output requests from software, translating them into data processing instructions for the central processing unit. It is also responsible for managing memory, and for managing and communicating with computing peripherals, like printers, speakers, etc. The kernel is a fundamental part of a modern computer's operating system.<br />
<br />
There are various alternative kernels available for Arch Linux in addition to the mainline Linux kernel. This article lists some of the options available in the repositories with a brief description of each. There is also a description of patches that can be applied to the system's kernel. The article ends with an overview of custom kernel compilation with links to various methods.<br />
<br />
==Precompiled kernels==<br />
===Official packages===<br />
;{{Pkg|linux}}<br />
:The Linux kernel and modules from the ''core'' repository. Vanilla kernel with [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux a few patches applied].<br />
<br />
;{{Pkg|linux-hardened}}<br />
:A security-focused Linux kernel applying a set of [https://github.com/thestinger/linux-hardened hardening patches] to mitigate kernel and userspace exploits. It also enables more upstream kernel hardening features than {{Pkg|Linux}} along with user namespaces (with unprivileged usage disabled by default via a patch), audit and [[SELinux]].<br />
<br />
;{{Pkg|linux-lts}}<br />
:Long term support (LTS) Linux kernel and modules from the ''core'' repository.<br />
<br />
;{{Pkg|linux-zen}}<br />
:The [https://github.com/zen-kernel/zen-kernel ZEN Kernel] is the result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems.<br />
<br />
===AUR packages===<br />
<br />
Note for [[AUR]] packages, "pre-compiled" means the packages are (usually) maintained, tested and verified to be working. Some of the listed packages may also be available as binary packages via [[Unofficial repositories]]. <br />
<br />
;{{AUR|linux-aufs_friendly}}<br />
:The aufs-compatible linux kernel and modules, useful when using [[docker]].<br />
<br />
;{{AUR|linux-cik}}<br />
:The Linux Kernel enabling support of extra graphic cards in [[AMDGPU]].<br />
<br />
;{{AUR|linux-ck}}<br />
:Linux Kernel built with Con Kolivas' ck1 patchset—see the [[#-ck]] section or the [[linux-ck]] page. Additional options which can be toggled on/off in the [[PKGBUILD]] include: BFQ scheduler, nconfig, localmodconfig and use running kernel's config.<br />
<br />
;{{AUR|linux-fbcondecor}}<br />
:The Linux Kernel and modules with [[Fbsplash|fbcondecor support]]. <br />
<br />
;{{AUR|linux-git}}<br />
:Linux kernel and modules built using sources from [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Linus Torvalds' Git repository].<br />
<br />
;{{AUR|linux-ice}}<br />
:The Linux Kernel and modules with gentoo-sources patchset and [[TuxOnIce]] support.<br />
<br />
;{{AUR|linux-libre}}, {{AUR|linux-libre-lts}}, {{AUR|linux-libre-rt}}, {{AUR|linux-libre-xen}}<br />
:The Linux Kernels without "binary blobs".<br />
<br />
;{{AUR|linux-lqx}}<br />
:[http://liquorix.net Liquorix] is a distro kernel replacement built using a Debian-targeted configuration and the ZEN kernel sources. Designed for desktop, multimedia, and gaming workloads, it is often used as a Debian Linux performance replacement kernel. Damentz, the maintainer of the Liquorix patchset, is a developer for the ZEN patchset as well.<br />
<br />
;{{AUR|linux-lts310}}<br />
:The Linux 3.10 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-lts312}}<br />
:The Linux 3.12 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-mainline}}<br />
:The Mainline Linux Kernel and modules.<br />
<br />
;{{AUR|linux-mptcp}}<br />
:The Linux Kernel and modules with [http://multipath-tcp.org/ Multipath TCP] support.<br />
<br />
;{{AUR|linux-pf}}<br />
:Linux kernel and modules with the pf-kernel patch [-ck patchset (BFS included), TuxOnIce, BFQ] and aufs3.<br />
<br />
;{{AUR|linux-rt}}<br />
:Linux kernel with the realtime patch set. Improves latency and introduces hard realtime support. https://rt.wiki.kernel.org/<br />
<br />
;{{AUR|linux-tresor}}/{{AUR|linux-lts-tresor}}<br />
:The current/LTS Linux Kernel and modules with integrated [https://www1.informatik.uni-erlangen.de/tresor TRESOR]<br />
<br />
;{{AUR|linux-vfio}}/{{AUR|linux-vfio-lts}}<br />
:The Linux kernel and a few patches written by Alex Williamson (acs override and i915) to enable the ability to do PCI Passthrough with KVM on some machines.<br />
<br />
==Patches and Patchsets==<br />
<br />
There are lots of reasons to patch your kernel, the major ones are for performance or support for non-mainline features such as reiser4 file system support. Other reasons might include fun and to see how it is done and what the improvements are.<br />
<br />
However, it is important to note that the best way to increase the speed of your system is to first tailor your kernel to your system, especially the architecture and processor type. For this reason using pre-packaged versions of custom kernels with generic architecture settings is not recommended or really worth it. A further benefit is that you can reduce the size of your kernel (and therefore build time) by not including support for things you do not have or use. For example, you might start with the stock kernel config when a new kernel version is released and remove support for things like bluetooth, video4linux, 1000Mbit ethernet, etc.; functionality you know you will not require for your specific machine. Although this page is not about customizing your kernel config, it is recommended as a first step--before moving on to using a patchset once you have grasped the fundamentals involved.<br />
<br />
The config files for the Arch kernel packages can be used as a starting point. They are in the Arch package source files, for example [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux] linked from {{Pkg|linux}}. The config file of your currently running kernel may also be available in your file system at {{ic|/proc/config.gz}} if the {{ic|CONFIG_IKCONFIG_PROC}} kernel option is enabled.<br />
<br />
===How to install===<br />
<br />
The installation process of custom kernel packages relies on the Arch Build System (ABS). If you have not built any custom packages yet you may consult the following articles: [[Arch Build System]] and [[Creating packages]].<br />
<br />
If you have not actually patched or customized a kernel before it is not that hard and there are many PKGBUILDs on the forum for individual patchsets. However, you are advised to start from scratch with a bit of research on the benefits of each patchset, rather than just arbitrarily picking one. This way you will learn much more about what you are doing rather than just choosing a kernel at startup and then be left wondering what it actually does.<br />
<br />
See [[#Compilation]].<br />
<br />
{{note|Do not forget to change the boot options in your bootloader, e.g. [[GRUB]], to use the new kernel.}}<br />
<br />
===Major patchsets===<br />
<br />
First of all it is important to note that patchsets are developed by a variety of people. Some of these people are actually involved in the production of the linux kernel and others are hobbyists, which may reflect its level of reliability and stability.<br />
<br />
It is also worth noting that some patchsets are built on the back of other patchsets (which may or may not be reflected in the title of the patch). Patchsets (and kernel updates) can be released '''very''' frequently and often it is not worth keeping up with ALL of them; so, do not go crazy, unless you make it your hobby!<br />
<br />
You can search Google for more sets, but remember to use quotes ({{ic|"-nitro"}}, for example); otherwise, Google will deliberately '''NOT''' show the results you want!<br />
<br />
{{note|This section is for '''information only''' - clearly no guarantees of stability or reliability are implied by inclusion on this page.}}<br />
<br />
====-ck====<br />
[[Linux-ck]] contains patches designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload. The patches are created and maintained by Con Kolivas, his site is at http://users.tpg.com.au/ckolivas/kernel/. Con maintains a full set but also provides the patches broken down so you can add only those you prefer.<br />
<br />
The -ck patches can be found at http://ck.kolivas.org/patches/<br />
<br />
====-rt====<br />
<br />
This patchset is maintained by a small group of core developers, led by Ingo Molnar. This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupt and software interrupts to kernel threads. <br />
<br />
It further incorporates high resolution timers - a patch set, which is independently maintained.<br />
<br />
[as said from the [https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch Real-Time Linux Wiki]]<br />
<br />
patch at https://www.kernel.org/pub/linux/kernel/projects/rt/<br />
<br />
====-bld====<br />
{{Warning|This patch is in development.}}<br />
BLD is best described as a O(1) CPU picking technique. Which is done by reordering CPU runqueues based on runqueue loads. In other words, it keeps the scheduler aware of the load changes, which helps scheduler to keep runqueues in an order. This technique does not depend on scheduler ticks. The two most simple things in this technique are: load tracking and runqueue ordering; these are relatively simpler operations. Load tracking will be done whenever a load change happens on the system and based on this load change runqueue will be ordered. So, if we have an ordered runqueue from lowest to highest, then picking the less (or even busiest) runqueue is easy. Scheduler can pick the lowest runqueue without calculation and comparison at the time of placing a task in a runqueue. And while trying to distribute load at sched_exec and sched_fork our best choice is to pick the lowest busiest runqueue of the system. And in this way, system remains balanced without doing any load balancing. At the time of try_to_wake_up picking the idlest runqueue is topmost priority but it has been done as per domain basis to utilize CPU cache properly and it's an area where more concentration is requires.<br />
<br />
Google Code web page: https://code.google.com/p/bld/<br />
<br />
====Tiny-Patches====<br />
The goal of [http://elinux.org/Linux_Tiny Linux Tiny] is to reduce its memory and disk footprint, as well as to add features to aid working on small systems. Target users are developers of embedded system and users of small or legacy machines such as 386s.<br />
<br />
Patch releases against the mainstream Linux kernel have been discontinued. The developers chose to focus on a few patches and spend their time trying to get them merged into the mainline kernel.<br />
<br />
====-pf====<br />
{{AUR|linux-pf}} is yet another Linux kernel fork which provides you with a handful of awesome features not merged into mainline. It is based on neither existing Linux fork nor patchset, although some unofficial ports may be used if required patches have not been released officially.<br />
The most prominent patches of linux-pf are TuxOnIce, the CK patchset (most notably BFS), AUFS3, LinuxIMQ, l7 filter and BFQ.<br />
<br />
See [[linux-pf]] for more information.<br />
<br />
===Individual patches===<br />
<br />
These are patches which can be simply included in any build of a vanilla kernel or incorporated (probably with some major tweaking) into another patchset.<br />
<br />
====Reiser4====<br />
<br />
[[Reiser4]]<br />
<br />
====fbsplash====<br />
[[fbsplash]]<br />
<br />
== Compilation ==<br />
Arch Linux provides for several methods of kernel compilation.<br />
<br />
=== Using the Arch Build System ===<br />
Using the [[Arch Build System]] takes advantage of the high quality of the existing {{Pkg|linux}} [[PKGBUILD]] and the benefits of [[Wikipedia:Package management system|package management]]. The PKGBUILD is structured so that you can stop the build after the source is downloaded and configure the kernel.<br />
<br />
See [[Kernels/Arch Build System]].<br />
<br />
=== Traditional ===<br />
This involves manually downloading a source tarball, and compiling in your home directory as a normal user. Once configured, two installation methods are available; the traditional manual method, or with [[Makepkg]] + [[Pacman]].<br />
<br />
See [[Kernels/Traditional compilation]].<br />
<br />
== See also ==<br />
*[http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (free ebook)</div>Thestingerhttps://wiki.archlinux.org/index.php?title=User:Thestinger&diff=476141User:Thestinger2017-05-07T17:33:47Z<p>Thestinger: update</p>
<hr />
<div>{{DISPLAYTITLE:User:thestinger}}<br />
*[[ArchWiki:Administrators|ArchWiki Admin]] (mostly inactive) and [[Trusted User]]<br />
* [https://www.archlinux.org/packages/?sort=&q=&maintainer=thestinger Official packages]<br />
* [https://aur.archlinux.org/packages.php?SeB=m&K=thestinger AUR packages] (not many left)</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476140Security2017-05-07T17:31:48Z<p>Thestinger: /* Sandboxing applications */ linux-hardened enables USER_NS, but with unprivileged usage disabled by default</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password), or enable ptrace selectively through {{ic|1=setcap cap_sys_ptrace=eip ''/path/to/program''}}.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications. The {{pkg|linux-hardened}} packages enables it but disables unprivileged usage by default unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|1}}, since it greatly increases the attack surface for local privilege escalation.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476139Security2017-05-07T17:29:02Z<p>Thestinger: /* Restricting access to kernel logs */ applies to other kernels too, not just core/linux</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password), or enable ptrace selectively through {{ic|1=setcap cap_sys_ptrace=eip ''/path/to/program''}}.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476138Security2017-05-07T17:28:38Z<p>Thestinger: /* Restricting access to kernel pointers in the proc filesystem */ move note</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}, but not {{pkg|linux}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password), or enable ptrace selectively through {{ic|1=setcap cap_sys_ptrace=eip ''/path/to/program''}}.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476137Security2017-05-07T17:28:22Z<p>Thestinger: /* Restricting access to kernel logs */ add a similar note</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Note|This is enabled by default in {{pkg|linux-hardened}}, but not {{pkg|linux}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default.}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password), or enable ptrace selectively through {{ic|1=setcap cap_sys_ptrace=eip ''/path/to/program''}}.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476136Security2017-05-07T17:27:47Z<p>Thestinger: /* Restricting access to kernel pointers in the proc filesystem */ conform to ridiculous mediawiki syntax</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default.}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password), or enable ptrace selectively through {{ic|1=setcap cap_sys_ptrace=eip ''/path/to/program''}}.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Security&diff=476135Security2017-05-07T17:27:32Z<p>Thestinger: /* Restricting access to kernel pointers in the proc filesystem */ default in linux-hardened</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
When relying on a passphrase, it must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using e.g. brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
Also consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method, using a sufficient number of words.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] or [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for some additional background. Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here], or consulting [[Wikipedia:Password strength]].<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more info).<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the pam_cracklib(8) and pam_unix(8) man pages for more information.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
{{Accuracy|You don't mount a partition, but a file system; i.e. this is not related to [[partitioning]]. In {{ic|fs.protected_hardlinks}} etc., the "fs" stands for "file system".}}<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, filesystems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
Partitions used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}. Potential usage is presented in the table below.<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1] [2]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam <sup>[2]</sup><br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
<sup>[2]</sup> Applications that use QML may crash or not work properly starting with Qt 5.8 if {{ic|noexec}} is set on these partitions. A workaround is available at [[Qt#Applications using QML crash or don't work with Qt 5.8]].<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user ''username'' --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo -e filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd -l root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit both {{ic|/etc/pam.d/su}} and {{ic|/etc/pam.d/su-l}}, then uncomment the line:<br />
<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
==== Denying ssh login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/thestinger/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults. See the [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project article on the Gentoo wiki] for some more information. It currently offers only a small subset of the previous {{ic|linux-grsec}} package providing the now private / commercial-only grsecurity patches, but the intention is for it to grow in scope alongside the upstream Kernel Self Protection Project. As much as possible will be landed upstream, but it can move ahead without waiting for changes to land and rejection of changes for political reasons won't stall it.<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|kptr_restrict=2}} by default.}}<br />
<br />
=== Keep BPF JIT compiler disabled ===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password), or enable ptrace selectively through {{ic|1=setcap cap_sys_ptrace=eip ''/path/to/program''}}.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program doesn't reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For [[Xorg]] to work, an exception needs to be added for systemd-logind:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
== Sandboxing applications ==<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is not set in the stock Arch kernel and may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
=== Firejail ===<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
[[bubblewrap]] is a setuid sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and Virtualbox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using other, more full virtualization options such as [[VirtualBox]], [[KVM]], or [[Xen]] can also improve security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
*See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
Avoid using [[Secure Shell]] without [[Secure Shell#Force public key authentication|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
[[Secure Shell#Deny|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[Dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy: <br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Follow NVD/CVE alerts ==<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch CVE Monitoring Team]].<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
== Physical security ==<br />
<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Bootloaders ===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Boot_partition|encrypted boot partitions]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Denying console login as root ===<br />
<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a username that exists on the system and that user's password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Block TTY access from X ===<br />
<br />
See [[Xorg#Block TTY access]].<br />
<br />
== Rebuilding packages ==<br />
<br />
{{Merge|DeveloperWiki:Security#Compiler / linker hardening|Details are missing, including what a wrapper can do but makepkg.conf flags can't (see [[DeveloperWiki:Security#hardening-wrapper]]).}}<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via {{Pkg|hardening-wrapper}}. <br />
<br />
=== Custom hardening flags ===<br />
<br />
While still a work in progress, the following build flags can be enabled in {{Ic|/etc/makepkg.conf}} as they are expected to become [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch default] flags in the future:<br />
<br />
* {{Ic|-z,now}} to LDFLAGS<br />
* {{Ic|-fno-plt -fstack-check}} to [[Wikipedia:CFLAGS|CFLAGS]]<br />
<br />
Using {{AUR|hardening-check}} to verify the status of the vanilla {{Ic|bzip2}} binary:<br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: no, normal executable!<br />
Stack protected: yes<br />
Fortify Source functions: no, only unprotected functions found!<br />
unprotected: fread<br />
unprotected: fprintf<br />
unprotected: strcat<br />
unprotected: strncpy<br />
unprotected: strcpy<br />
Read-only relocations: no, not found!<br />
Immediate binding: no, not found!<br />
<br />
Using {{AUR|hardening-check}} to verify the status of a hardened {{Ic|bzip2}} ''binary'': <br />
<br />
$ hardening check -v /usr/bin/bzip2<br />
/usr/bin/bzip2:<br />
Position Independent Executable: yes<br />
Stack protected: yes<br />
Fortify Source functions: yes (some protected functions found)<br />
unprotected: memcpy<br />
unprotected: fread<br />
unprotected: strncpy<br />
protected: fprintf<br />
protected: strcat<br />
Read-only relocations: yes<br />
Immediate binding: yes<br />
<br />
Using {{Pkg|checksec}} to verify the status of the vanilla {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
Using {{Pkg|checksec}} to verify the status of a hardened {{Ic|bzip2}} binary: <br />
<br />
$ checksec -f /usr/bin/bzip2<br />
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE<br />
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2<br />
<br />
{{Note|Certain packages are known to fail with PIE enabled. {{Ic|1=export HARDENING_PIE=0}} as a workaround.}}<br />
<br />
== See also ==<br />
* [[DeveloperWiki:Security]]<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [[List of applications/Security|ArchWiki: Security Applications]]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=SELinux&diff=476134SELinux2017-05-07T17:25:31Z<p>Thestinger: /* Current status in Arch Linux */ audit support</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:SELinux]]<br />
[[ru:SELinux]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|AppArmor}}<br />
{{Related articles end}}<br />
<br />
Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style mandatory access controls (MAC), through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.<br />
<br />
Running SELinux under a Linux distribution requires three things: An SELinux enabled kernel, SELinux Userspace tools and libraries, and SELinux Policies (mostly based on the Reference Policy). Some common Linux programs will also need to be patched/compiled with SELinux features.<br />
<br />
==Current status in Arch Linux==<br />
<br />
SELinux is not officially supported (see [https://lists.archlinux.org/pipermail/arch-general/2013-October/034352.html][https://lists.archlinux.org/pipermail/arch-general/2017-February/043149.html]). The status of unofficial support is:<br />
<br />
{| class="wikitable"<br />
! Name !! Status !! Available at<br />
|-<br />
| SELinux enabled kernel || Implemented for {{pkg|linux-hardened}}, but not {{pkg|linux}} || Removed since the 3.14 official {{pkg|linux}} kernel.<br />
|-<br />
| SELinux Userspace tools and libraries || Implemented in AUR: https://aur.archlinux.org/packages/?O=0&K=selinux || Work is done at https://github.com/archlinuxhardened/selinux<br />
|-<br />
| SELinux Policy || Work in progress, using [https://github.com/TresysTechnology/refpolicy Reference Policy] as upstream || Work in progress at https://github.com/archlinuxhardened/selinux-policy-arch/<br />
|}<br />
<br />
Summary of changes in AUR as compared to official core packages:<br />
<br />
{| class="wikitable"<br />
! Name !! Status and comments<br />
|-<br />
| linux || Need a rebuild with some KConfig options enabled<br />
|-<br />
| linux-hardened || SELinux support enabled, but audit support is disabled by default and needs to be enabled with audit=1 on the kernel line<br />
|-<br />
| coreutils || Need a rebuild with {{ic|--with-selinux}} flag to link with libselinux<br />
|-<br />
| cronie || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| dbus || Need a rebuild with {{ic|--enable-libaudit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| findutils || Need a rebuild with libselinux installed to enable SELinux-specific options<br />
|-<br />
| iproute2 || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| logrotate || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| openssh || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| pam || Need a rebuild with {{ic|--enable-selinux}} flag for Linux-PAM ; Need a patch for pam_unix2, which only removes a function already implemented in a recent versions of libselinux<br />
|-<br />
| pambase || Configuration changes to add pam_selinux.so to {{ic|/etc/pam.d/system-login}}<br />
|-<br />
| psmisc || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| shadow || Need a rebuild with {{ic|--with-selinux}} flags<br />
|-<br />
| sudo || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| systemd || Need a rebuild with {{ic|--enable-audit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| util-linux || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
|}<br />
<br />
All of the other SELinux-related packages may be included without changes nor risks.<br />
<br />
==Concepts: Mandatory Access Controls==<br />
<br />
{{Note|This section is meant for beginners. If you know what SELinux does and how it works, feel free to skip ahead to the installation.}}<br />
<br />
Before you enable SELinux, it is worth understanding what it does. Simply and succinctly, SELinux enforces ''Mandatory Access Controls (MACs)'' on Linux. In contrast to SELinux, the traditional user/group/rwx permissions are a form of ''Discretionary Access Control (DAC)''. MACs are different from DACs because security policy and its execution are completely separated.<br />
<br />
An example would be the use of the ''sudo'' command. When DACs are enforced, sudo allows temporary privilege escalation to root, giving the process so spawned unrestricted systemwide access. However, when using MACs, if the security administrator deems the process to have access only to a certain set of files, then no matter what the kind of privilege escalation used, unless the security policy itself is changed, the process will remain constrained to simply that set of files. So if ''sudo'' is tried on a machine with SELinux running in order for a process to gain access to files its policy does not allow, it will fail.<br />
<br />
Another set of examples are the traditional (-rwxr-xr-x) type permissions given to files. When under DAC, these are user-modifiable. However, under MAC, a security administrator can choose to freeze the permissions of a certain file by which it would become impossible for any user to change these permissions until the policy regarding that file is changed.<br />
<br />
As you may imagine, this is particularly useful for processes which have the potential to be compromised, i.e. web servers and the like. If DACs are used, then there is a particularly good chance of havoc being wreaked by a compromised program which has access to privilege escalation.<br />
<br />
For further information, visit [[wikipedia:Mandatory access control]].<br />
<br />
==Installing SELinux==<br />
<br />
===Package description===<br />
<br />
All SELinux related packages belong to the ''selinux'' group in the AUR.<br />
<br />
====SELinux aware system utilities====<br />
<br />
;{{AUR|coreutils-selinux}}<br />
:Modified coreutils package compiled with SELinux support enabled. It replaces the {{pkg|coreutils}} package<br />
<br />
;{{AUR|ustr-selinux}}<br />
:Patched ustr package needed only to build {{AUR|libsemanage}}. It replaces the {{pkg|ustr}} package, which does not work with recent gcc ({{bug|46445}}).<br />
<br />
;{{AUR|pam-selinux}} and {{AUR|pambase-selinux}}<br />
:PAM package with pam_selinux.so. and the underlying base package. They replace the {{pkg|pam}} and {{pkg|pambase}} packages respectively.<br />
<br />
;{{AUR|util-linux-selinux}}<br />
:Modified util-linux package compiled with SELinux support enabled. It replaces the {{pkg|util-linux}} package.<br />
<br />
;{{AUR|systemd-selinux}}<br />
:An SELinux aware version of [[Systemd]]. It replaces the {{pkg|systemd}} package.<br />
<br />
;{{AUR|dbus-selinux}}<br />
:An SELinux aware version of [[D-Bus]]. It replaces the {{pkg|dbus}} package.<br />
<br />
;{{AUR|findutils-selinux}}<br />
:Patched findutils package compiled with SELinux support to make searching of files with specified security context possible. It replaces the {{pkg|findutils}} package.<br />
<br />
;{{AUR|iproute2-selinux}}<br />
:iproute2 package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|ss}}. It replaces the {{pkg|iproute2}} package.<br />
<br />
;{{AUR|psmisc-selinux}}<br />
:Psmisc package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|killall}}. It replaces the {{pkg|psmisc}} package.<br />
<br />
;{{AUR|shadow-selinux}}<br />
:Shadow package compiled with SELinux support; contains a modified {{ic|/etc/pam.d/login}} file to set correct security context for user after login. It replaces the {{pkg|shadow}} package.<br />
<br />
;{{AUR|sudo-selinux}}<br />
:Modified [[sudo]] package compiled with SELinux support which sets the security context correctly. It replaces the {{pkg|sudo}} package.<br />
<br />
;{{AUR|cronie-selinux}}<br />
:Fedora fork of Vixie cron with SELinux enabled. It replaces the {{pkg|cronie}} package.<br />
<br />
;{{AUR|logrotate-selinux}}<br />
:Logrotate package compiled with SELinux support. It replaces the {{pkg|logrotate}} package.<br />
<br />
;{{AUR|openssh-selinux}}<br />
:[[OpenSSH]] package compiled with SELinux support to set security context for user sessions. It replaces the {{pkg|openssh}} package.<br />
<br />
====SELinux userspace utilities====<br />
;{{AUR|checkpolicy}}<br />
:Tools to build SELinux policy<br />
<br />
;{{AUR|libselinux}}<br />
:Library for security-aware applications. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsemanage}}<br />
:Library for policy management. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsepol}}<br />
:Library for binary policy manipulation.<br />
<br />
;{{AUR|policycoreutils}}<br />
:SELinux core utils such as newrole, setfiles, etc.<br />
<br />
;{{AUR|sepolgen}}<br />
:A Python library for parsing and modifying policy source.<br />
<br />
====SELinux policy packages====<br />
<br />
;{{AUR|selinux-refpolicy-src}}<br />
:Reference policy sources<br />
<br />
;{{AUR|selinux-refpolicy-arch}}<br />
:Precompiled modular Reference policy with headers and documentation but without sources. Development Arch Linux Refpolicy patches included, which fixes issues related to path labeling and systemd support. These patches are also sent to Reference Policy maintainers and their inclusion in {{AUR|selinux-refpolicy-arch}} is mainly a way to perform updates between Refpolicy releases.<br />
<br />
====Other SELinux tools====<br />
<br />
;{{AUR|setools}}<br />
:CLI and GUI tools to manage SELinux<br />
<br />
=== Installation ===<br />
<br />
===Preparing the Kernel===<br />
<br />
Only ext2, ext3, ext4, JFS, XFS and BtrFS filesystems are supported to use SELinux. By default, the Arch Kernel does not have the SELinux LSM enabled. If you are using Arch Linux packaged kernel ({{pkg|linux}}), there is an AUR package which adds the configuration options for SELinux, {{aur|linux-selinux}}. Otherwise, when you are using a custom kernel, please do make sure that Xattr (Extended Attributes), {{ic|CONFIG_AUDIT}} and {{ic|CONFIG_SECURITY_SELINUX}} are enabled in your config. (Source: [http://wiki.debian.org/SELinux/Setup#kernel Debian Wiki])<br />
<br />
Here is the complete list of options which need to be enabled on Linux 4.3.3 to use SELinux :<br />
{{hc|config.selinux-custom|<nowiki>CONFIG_AUDIT=y<br />
CONFIG_AUDITSYSCALL=y<br />
CONFIG_AUDIT_WATCH=y<br />
CONFIG_AUDIT_TREE=y<br />
CONFIG_NETLABEL=y<br />
CONFIG_IP_NF_SECURITY=m<br />
CONFIG_IP6_NF_SECURITY=m<br />
CONFIG_NETFILTER_XT_TARGET_AUDIT=m<br />
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y<br />
CONFIG_NFSD_V4_SECURITY_LABEL=y<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_PATH=y<br />
CONFIG_LSM_MMAP_MIN_ADDR=65536<br />
CONFIG_SECURITY_SELINUX=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM=y<br />
CONFIG_SECURITY_SELINUX_DISABLE=y<br />
CONFIG_SECURITY_SELINUX_DEVELOP=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1<br />
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1<br />
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y<br />
CONFIG_SECURITY_SELINUX_AVC_STATS=y<br />
CONFIG_DEFAULT_SECURITY_SELINUX=y</nowiki>}}<br />
<br />
{{Note|If using proprietary drivers, such as [[NVIDIA]] graphics drivers, you may need to [[NVIDIA#Custom kernel|rebuild them]].}}<br />
<br />
There are two methods to install the requisite SELinux packages.<br />
<br />
==== Via AUR ====<br />
<br />
* First, install SELinux userspace tools and libraries, in this order (because of the dependencies): {{AUR|libsepol}}, {{AUR|libselinux}}, {{AUR|checkpolicy}}, {{AUR|setools}}, {{AUR|ustr-selinux}}, {{AUR|libsemanage}} (which needs {{pkg|python2-ipy}} from the ''community'' repository) and {{AUR|sepolgen}}.<br />
* Then install {{AUR|pambase-selinux}} and {{AUR|pam-selinux}} and make sure you can login again after the installation completed , because files in {{ic|/etc/pam.d/}} got removed and created when {{pkg|pambase}} got replaced with {{AUR|pambase-selinux}}.<br />
* Next you can install {{AUR|libcgroup}} and {{AUR|policycoreutils}}, before recompiling some core packages by installing: {{AUR|coreutils-selinux}}, {{AUR|findutils-selinux}}, {{AUR|iproute2-selinux}}, {{AUR|logrotate-selinux}}, {{AUR|openssh-selinux}}, {{AUR|psmisc-selinux}}, {{AUR|shadow-selinux}}, {{AUR|cronie-selinux}}<br />
* Next, backup your {{ic|/etc/sudoers}} file. Install {{AUR|sudo-selinux}} and restore your {{ic|/etc/sudoers}} (it is overridden when this package is installed as a replacement of {{pkg|sudo}}).<br />
* Next come util-linux and systemd. Because of a cyclic makedepends between these two packages which will not be fixed ({{bug|39767}}), you need to build the source package {{AUR|systemd-selinux}}, install {{AUR|libsystemd-selinux}}, build and install {{AUR|util-linux-selinux}} (with {{AUR|libutil-linux-selinux}}) and rebuild and install {{AUR|systemd-selinux}}.<br />
* Next, install {{AUR|dbus-selinux}}.<br />
<br />
After all these steps, you can install a SELinux kernel (like {{AUR|linux-selinux}}) and a policy (like {{AUR|selinux-refpolicy-arch}}).<br />
<br />
==== Using the GitHub repository ====<br />
<br />
All packages are maintained at https://github.com/archlinuxhardened/selinux . This repository also contains a script named {{ic|build_and_install_all.sh}} which builds and installs (or updates) all packages in the needed order. Here is an example of a way this script can be used in a user shell to install all packages (with downloading the GPG keys which are used to verify the source tarballs of the package):<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux<br />
./recv_gpg_keys.sh<br />
./build_and_install_all.sh<br />
<br />
Of course, it is possible to modify the content of {{ic|build_and_install_all.sh}} before running it, for example if you already have SELinux support in your kernel.<br />
<br />
===Changing boot loader configuration===<br />
<br />
If you have installed a new kernel, make sure that you update your bootloader accordingly to boot on it. Moreover you may need to add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to the kernel command line. More precisely, if the kernel configuration does not set {{ic|CONFIG_DEFAULT_SECURITY_SELINUX}}, {{ic|<nowiki>security=selinux</nowiki>}} is needed, and if it contains {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM=y</nowiki>}} {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0</nowiki>}}, {{ic|<nowiki>selinux=1</nowiki>}} is needed.<br />
<br />
====GRUB====<br />
<br />
Add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variable in {{ic|/etc/default/grub}}<br />
Run the following command:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
====Syslinux====<br />
<br />
Change your syslinux.cfg file by adding:<br />
<br />
{{hc|/boot/syslinux/syslinux.cfg|<nowiki>LABEL arch-selinux<br />
LINUX ../vmlinuz-linux-selinux<br />
APPEND root=/dev/sda2 ro security=selinux selinux=1<br />
INITRD ../initramfs-linux-selinux.img</nowiki>}}<br />
<br />
at the end. Change "linux-selinux" to whatever kernel you are using.<br />
<br />
====systemd-boot====<br />
<br />
Create a new loader entry, for example in {{ic|/boot/loader/entries/arch-selinux.conf}}:<br />
<br />
{{hc|/boot/loader/entries/arch-selinux.conf|2=<br />
title Arch Linux SELinux<br />
linux /vmlinuz-linux-selinux<br />
initrd /initramfs-linux-selinux.img<br />
options root=/dev/sda2 ro selinux=1 security=selinux<br />
}}<br />
<br />
===Checking PAM===<br />
<br />
A correctly set-up [[PAM]] is important to get the proper security context after login. Check for the presence of the following lines in {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{bc|# pam_selinux.so close should be the first session rule<br />
session required pam_selinux.so close}}<br />
<br />
{{bc|# pam_selinux.so open should only be followed by sessions to be executed in the user context<br />
session required pam_selinux.so open}}<br />
<br />
===Installing a policy===<br />
<br />
{{Warning|The reference policy as given by [http://oss.tresys.com/projects/refpolicy Tresys] is not very good for Arch Linux, as almost no file is labelled correctly. However, as of writing, Archers have no other choice. If anyone has made any significant strides in addressing this problem, they are encouraged to share it, preferably on the [[AUR]]. The major problems are:<br />
<br />
* {{ic|/lib}} and {{ic|/usr/lib}} are considered different (and also {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/bin}} and {{ic|/usr/sbin}}). This introduces some instability when applying labels to the whole system, as files in these folders may be seen with 2 (or 4) different labels. <br />
* systemd is not yet supported (C. PeBenito, main developer of the refpolicy, announced its willingness to work on it in its github repository in October 2014, http://oss.tresys.com/pipermail/refpolicy/2014-October/007430.html)}}<br />
<br />
Policies are the mainstay of SELinux. They are what govern its behaviour. The only policy currently available in the AUR is the Reference Policy. In order to install it, you should use the source files, which may be got from the package {{AUR|selinux-refpolicy-src}} or by downloading the latest release on https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease#current-release. When using the AUR package, navigate to {{ic|/etc/selinux/refpolicy/src/policy}} and run the following commands:<br />
<br />
{{bc|# make bare<br />
# make conf<br />
# make install}}<br />
<br />
to install the reference policy as it is. Those who know how to write SELinux policies can tweak them to their heart's content before running the commands written above. The command takes a while to do its job and taxes one core of your system completely, so do not worry. Just sit back and let the command run for as long as it takes.<br />
<br />
To load the reference policy run:<br />
{{bc|# make load}}<br />
<br />
Then, make the file {{ic|/etc/selinux/config}} with the following contents (Only works if you used the defaults as mentioned above. If you decided to change the name of the policy, you need to tweak the file):<br />
<br />
{{hc|/etc/selinux/config|<nowiki># This file controls the state of SELinux on the system.<br />
# SELINUX= can take one of these three values:<br />
# enforcing - SELinux security policy is enforced.<br />
# Set this value once you know for sure that SELinux is configured the way you like it and that your system is ready for deployment<br />
# permissive - SELinux prints warnings instead of enforcing.<br />
# Use this to customise your SELinux policies and booleans prior to deployment. Recommended during policy development.<br />
# disabled - No SELinux policy is loaded.<br />
# This is not a recommended setting, for it may cause problems with file labelling<br />
SELINUX=permissive<br />
# SELINUXTYPE= takes the name of SELinux policy to<br />
# be used. Current options are:<br />
# refpolicy (vanilla reference policy)<br />
# <custompolicy> - Substitute <custompolicy> with the name of any custom policy you choose to load<br />
SELINUXTYPE=refpolicy</nowiki>}}<br />
<br />
Now, you may reboot. After rebooting, run:<br />
<br />
# restorecon -r /<br />
<br />
to label your filesystem.<br />
<br />
Now, make a file {{ic|requiredmod.te}} with the contents:<br />
<br />
{{hc|requiredmod.te|<nowiki>module requiredmod 1.0;<br />
<br />
require {<br />
type devpts_t;<br />
type kernel_t;<br />
type device_t;<br />
type var_run_t;<br />
type udev_t;<br />
type hugetlbfs_t;<br />
type udev_tbl_t;<br />
type tmpfs_t;<br />
class sock_file write;<br />
class unix_stream_socket { read write ioctl };<br />
class capability2 block_suspend;<br />
class dir { write add_name };<br />
class filesystem associate;<br />
}<br />
<br />
#============= devpts_t ==============<br />
allow devpts_t device_t:filesystem associate;<br />
<br />
#============= hugetlbfs_t ==============<br />
allow hugetlbfs_t device_t:filesystem associate;<br />
<br />
#============= kernel_t ==============<br />
allow kernel_t self:capability2 block_suspend;<br />
<br />
#============= tmpfs_t ==============<br />
allow tmpfs_t device_t:filesystem associate;<br />
<br />
#============= udev_t ==============<br />
allow udev_t kernel_t:unix_stream_socket { read write ioctl };<br />
allow udev_t udev_tbl_t:dir { write add_name };<br />
allow udev_t var_run_t:sock_file write;</nowiki>}}<br />
<br />
and run the following commands:<br />
<br />
{{bc|<nowiki># checkmodule -m -o requiredmod.mod requiredmod.te<br />
# semodule_package -o requiredmod.pp -m requiredmod.mod<br />
# semodule -i requiredmod.pp</nowiki>}}<br />
<br />
This is required to remove a few messages from {{ic|/var/log/audit/audit.log}} which are a nuisance to deal with in the reference policy. This is an ugly hack and it should be made very clear that the policy so installed simply patches the reference policy in order to hide the effects of incorrect labelling.<br />
<br />
===Testing in a Vagrant virtual machine===<br />
<br />
It is possible to use [[Vagrant]] to provision a virtual Arch Linux machine with SELinux configured. This is a convenient way to test an Arch Linux system running SELinux without modifying a current system. Here are commands which can be used to achieve this:<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux/_vagrant<br />
vagrant up<br />
vagrant ssh<br />
<br />
==Post-installation steps==<br />
<br />
You can check that SELinux is working with {{ic|sestatus}}. You should get something like:<br />
<br />
{{bc|<nowiki>SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
SELinux root directory: /etc/selinux<br />
Loaded policy name: refpolicy<br />
Current mode: permissive<br />
Mode from config file: permissive<br />
Policy MLS status: disabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 28</nowiki>}}<br />
<br />
To maintain correct context, you can use ''restorecond'':<br />
<br />
# systemctl enable restorecond<br />
<br />
To switch to enforcing mode without rebooting, you can use:<br />
<br />
# echo 1 > /sys/fs/selinux/enforce<br />
<br />
===Swapfiles===<br />
<br />
If you have a swap file instead of a swap partition, issue the following commands in order to set the appropriate security context:<br />
<br />
{{bc|# semanage fcontext -a -t swapfile_t "/path/to/swapfile"<br />
# restorecon /path/to/swapfile}}<br />
<br />
==Working with SELinux==<br />
<br />
SELinux defines security using a different mechanism than traditional Unix access controls. The best way to understand it is by example. For example, the SELinux security context of the apache homepage looks like the following:<br />
<br />
$ls -lZ /var/www/html/index.html<br />
-rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html<br />
<br />
The first three and the last columns should be familiar to any (Arch) Linux user. The fourth column is new and has the format:<br />
<br />
user:role:type[:level]<br />
<br />
To explain:<br />
#'''User:''' The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br />
#'''Role:''' The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br />
#'''Type:''' When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br />
#'''Level:''' This optional field can also be know as a range and is only present if the policy supports MCS or MLS.<br />
<br />
This is important in case you wish to understand how to build your own policies, for these are the basic building blocks of SELinux. However, for most purposes, there is no need to, for the reference policy is sufficiently mature. However, if you are a power user or someone with very specific needs, then it might be ideal for you to learn how to make your own SELinux policies.<br />
<br />
[http://www.fosteringlinux.com/tag/selinux/ This] is a great series of articles for someone seeking to understand how to work with SELinux.<br />
<br />
==Troubleshooting==<br />
<br />
The place to look for SELinux errors is the systemd journal. In order to see SELinux messages related to the label {{ic|system_u:system_r:policykit_t:s0}} (for example), you would need to run:<br />
<br />
# journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0<br />
<br />
===Useful tools===<br />
<br />
There are some tools/commands that can greatly help with SELinux. <br />
<br />
;restorecon: Restores the context of a file/directory (or recursively with {{ic|-R}}) based on any policy rules <br />
;chcon: Change the context on a specific file<br />
<br />
===Reporting issues===<br />
<br />
Please report issues on GitHub: https://github.com/archlinuxhardened/selinux/issues<br />
<br />
==See also==<br />
*[[wikipedia:Security-Enhanced_Linux|Security Enhanced Linux]]<br />
*[http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml Gentoo SELinux Handbook]<br />
*[http://fedoraproject.org/wiki/SELinux Fedora Project's SELinux Wiki]<br />
*[http://www.nsa.gov/research/selinux/index.shtml NSA's Official SELinux Homepage]<br />
*[http://oss.tresys.com/projects/refpolicy Reference Policy Homepage]<br />
*[http://userspace.selinuxproject.org/trac/ SELinux Userspace Homepage]<br />
*[http://oss.tresys.com/projects/setools SETools Homepage]<br />
*[https://web.archive.org/web/20140816115906/http://jamesthebard.net/archlinux-selinux-and-you-a-trip-down-the-rabbit-hole/ ArchLinux, SELinux and You (archived)]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=SELinux&diff=476133SELinux2017-05-07T17:25:01Z<p>Thestinger: /* Current status in Arch Linux */ rw</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:SELinux]]<br />
[[ru:SELinux]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|AppArmor}}<br />
{{Related articles end}}<br />
<br />
Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style mandatory access controls (MAC), through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.<br />
<br />
Running SELinux under a Linux distribution requires three things: An SELinux enabled kernel, SELinux Userspace tools and libraries, and SELinux Policies (mostly based on the Reference Policy). Some common Linux programs will also need to be patched/compiled with SELinux features.<br />
<br />
==Current status in Arch Linux==<br />
<br />
SELinux is not officially supported (see [https://lists.archlinux.org/pipermail/arch-general/2013-October/034352.html][https://lists.archlinux.org/pipermail/arch-general/2017-February/043149.html]). The status of unofficial support is:<br />
<br />
{| class="wikitable"<br />
! Name !! Status !! Available at<br />
|-<br />
| SELinux enabled kernel || Implemented for {{pkg|linux-hardened}}, but not {{pkg|linux}} || Removed since the 3.14 official {{pkg|linux}} kernel.<br />
|-<br />
| SELinux Userspace tools and libraries || Implemented in AUR: https://aur.archlinux.org/packages/?O=0&K=selinux || Work is done at https://github.com/archlinuxhardened/selinux<br />
|-<br />
| SELinux Policy || Work in progress, using [https://github.com/TresysTechnology/refpolicy Reference Policy] as upstream || Work in progress at https://github.com/archlinuxhardened/selinux-policy-arch/<br />
|}<br />
<br />
Summary of changes in AUR as compared to official core packages:<br />
<br />
{| class="wikitable"<br />
! Name !! Status and comments<br />
|-<br />
| linux || Need a rebuild with some KConfig options enabled<br />
|-<br />
| linux-hardened || SELinux support enabled<br />
|-<br />
| coreutils || Need a rebuild with {{ic|--with-selinux}} flag to link with libselinux<br />
|-<br />
| cronie || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| dbus || Need a rebuild with {{ic|--enable-libaudit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| findutils || Need a rebuild with libselinux installed to enable SELinux-specific options<br />
|-<br />
| iproute2 || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| logrotate || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| openssh || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| pam || Need a rebuild with {{ic|--enable-selinux}} flag for Linux-PAM ; Need a patch for pam_unix2, which only removes a function already implemented in a recent versions of libselinux<br />
|-<br />
| pambase || Configuration changes to add pam_selinux.so to {{ic|/etc/pam.d/system-login}}<br />
|-<br />
| psmisc || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| shadow || Need a rebuild with {{ic|--with-selinux}} flags<br />
|-<br />
| sudo || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| systemd || Need a rebuild with {{ic|--enable-audit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| util-linux || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
|}<br />
<br />
All of the other SELinux-related packages may be included without changes nor risks.<br />
<br />
==Concepts: Mandatory Access Controls==<br />
<br />
{{Note|This section is meant for beginners. If you know what SELinux does and how it works, feel free to skip ahead to the installation.}}<br />
<br />
Before you enable SELinux, it is worth understanding what it does. Simply and succinctly, SELinux enforces ''Mandatory Access Controls (MACs)'' on Linux. In contrast to SELinux, the traditional user/group/rwx permissions are a form of ''Discretionary Access Control (DAC)''. MACs are different from DACs because security policy and its execution are completely separated.<br />
<br />
An example would be the use of the ''sudo'' command. When DACs are enforced, sudo allows temporary privilege escalation to root, giving the process so spawned unrestricted systemwide access. However, when using MACs, if the security administrator deems the process to have access only to a certain set of files, then no matter what the kind of privilege escalation used, unless the security policy itself is changed, the process will remain constrained to simply that set of files. So if ''sudo'' is tried on a machine with SELinux running in order for a process to gain access to files its policy does not allow, it will fail.<br />
<br />
Another set of examples are the traditional (-rwxr-xr-x) type permissions given to files. When under DAC, these are user-modifiable. However, under MAC, a security administrator can choose to freeze the permissions of a certain file by which it would become impossible for any user to change these permissions until the policy regarding that file is changed.<br />
<br />
As you may imagine, this is particularly useful for processes which have the potential to be compromised, i.e. web servers and the like. If DACs are used, then there is a particularly good chance of havoc being wreaked by a compromised program which has access to privilege escalation.<br />
<br />
For further information, visit [[wikipedia:Mandatory access control]].<br />
<br />
==Installing SELinux==<br />
<br />
===Package description===<br />
<br />
All SELinux related packages belong to the ''selinux'' group in the AUR.<br />
<br />
====SELinux aware system utilities====<br />
<br />
;{{AUR|coreutils-selinux}}<br />
:Modified coreutils package compiled with SELinux support enabled. It replaces the {{pkg|coreutils}} package<br />
<br />
;{{AUR|ustr-selinux}}<br />
:Patched ustr package needed only to build {{AUR|libsemanage}}. It replaces the {{pkg|ustr}} package, which does not work with recent gcc ({{bug|46445}}).<br />
<br />
;{{AUR|pam-selinux}} and {{AUR|pambase-selinux}}<br />
:PAM package with pam_selinux.so. and the underlying base package. They replace the {{pkg|pam}} and {{pkg|pambase}} packages respectively.<br />
<br />
;{{AUR|util-linux-selinux}}<br />
:Modified util-linux package compiled with SELinux support enabled. It replaces the {{pkg|util-linux}} package.<br />
<br />
;{{AUR|systemd-selinux}}<br />
:An SELinux aware version of [[Systemd]]. It replaces the {{pkg|systemd}} package.<br />
<br />
;{{AUR|dbus-selinux}}<br />
:An SELinux aware version of [[D-Bus]]. It replaces the {{pkg|dbus}} package.<br />
<br />
;{{AUR|findutils-selinux}}<br />
:Patched findutils package compiled with SELinux support to make searching of files with specified security context possible. It replaces the {{pkg|findutils}} package.<br />
<br />
;{{AUR|iproute2-selinux}}<br />
:iproute2 package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|ss}}. It replaces the {{pkg|iproute2}} package.<br />
<br />
;{{AUR|psmisc-selinux}}<br />
:Psmisc package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|killall}}. It replaces the {{pkg|psmisc}} package.<br />
<br />
;{{AUR|shadow-selinux}}<br />
:Shadow package compiled with SELinux support; contains a modified {{ic|/etc/pam.d/login}} file to set correct security context for user after login. It replaces the {{pkg|shadow}} package.<br />
<br />
;{{AUR|sudo-selinux}}<br />
:Modified [[sudo]] package compiled with SELinux support which sets the security context correctly. It replaces the {{pkg|sudo}} package.<br />
<br />
;{{AUR|cronie-selinux}}<br />
:Fedora fork of Vixie cron with SELinux enabled. It replaces the {{pkg|cronie}} package.<br />
<br />
;{{AUR|logrotate-selinux}}<br />
:Logrotate package compiled with SELinux support. It replaces the {{pkg|logrotate}} package.<br />
<br />
;{{AUR|openssh-selinux}}<br />
:[[OpenSSH]] package compiled with SELinux support to set security context for user sessions. It replaces the {{pkg|openssh}} package.<br />
<br />
====SELinux userspace utilities====<br />
;{{AUR|checkpolicy}}<br />
:Tools to build SELinux policy<br />
<br />
;{{AUR|libselinux}}<br />
:Library for security-aware applications. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsemanage}}<br />
:Library for policy management. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsepol}}<br />
:Library for binary policy manipulation.<br />
<br />
;{{AUR|policycoreutils}}<br />
:SELinux core utils such as newrole, setfiles, etc.<br />
<br />
;{{AUR|sepolgen}}<br />
:A Python library for parsing and modifying policy source.<br />
<br />
====SELinux policy packages====<br />
<br />
;{{AUR|selinux-refpolicy-src}}<br />
:Reference policy sources<br />
<br />
;{{AUR|selinux-refpolicy-arch}}<br />
:Precompiled modular Reference policy with headers and documentation but without sources. Development Arch Linux Refpolicy patches included, which fixes issues related to path labeling and systemd support. These patches are also sent to Reference Policy maintainers and their inclusion in {{AUR|selinux-refpolicy-arch}} is mainly a way to perform updates between Refpolicy releases.<br />
<br />
====Other SELinux tools====<br />
<br />
;{{AUR|setools}}<br />
:CLI and GUI tools to manage SELinux<br />
<br />
=== Installation ===<br />
<br />
===Preparing the Kernel===<br />
<br />
Only ext2, ext3, ext4, JFS, XFS and BtrFS filesystems are supported to use SELinux. By default, the Arch Kernel does not have the SELinux LSM enabled. If you are using Arch Linux packaged kernel ({{pkg|linux}}), there is an AUR package which adds the configuration options for SELinux, {{aur|linux-selinux}}. Otherwise, when you are using a custom kernel, please do make sure that Xattr (Extended Attributes), {{ic|CONFIG_AUDIT}} and {{ic|CONFIG_SECURITY_SELINUX}} are enabled in your config. (Source: [http://wiki.debian.org/SELinux/Setup#kernel Debian Wiki])<br />
<br />
Here is the complete list of options which need to be enabled on Linux 4.3.3 to use SELinux :<br />
{{hc|config.selinux-custom|<nowiki>CONFIG_AUDIT=y<br />
CONFIG_AUDITSYSCALL=y<br />
CONFIG_AUDIT_WATCH=y<br />
CONFIG_AUDIT_TREE=y<br />
CONFIG_NETLABEL=y<br />
CONFIG_IP_NF_SECURITY=m<br />
CONFIG_IP6_NF_SECURITY=m<br />
CONFIG_NETFILTER_XT_TARGET_AUDIT=m<br />
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y<br />
CONFIG_NFSD_V4_SECURITY_LABEL=y<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_PATH=y<br />
CONFIG_LSM_MMAP_MIN_ADDR=65536<br />
CONFIG_SECURITY_SELINUX=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM=y<br />
CONFIG_SECURITY_SELINUX_DISABLE=y<br />
CONFIG_SECURITY_SELINUX_DEVELOP=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1<br />
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1<br />
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y<br />
CONFIG_SECURITY_SELINUX_AVC_STATS=y<br />
CONFIG_DEFAULT_SECURITY_SELINUX=y</nowiki>}}<br />
<br />
{{Note|If using proprietary drivers, such as [[NVIDIA]] graphics drivers, you may need to [[NVIDIA#Custom kernel|rebuild them]].}}<br />
<br />
There are two methods to install the requisite SELinux packages.<br />
<br />
==== Via AUR ====<br />
<br />
* First, install SELinux userspace tools and libraries, in this order (because of the dependencies): {{AUR|libsepol}}, {{AUR|libselinux}}, {{AUR|checkpolicy}}, {{AUR|setools}}, {{AUR|ustr-selinux}}, {{AUR|libsemanage}} (which needs {{pkg|python2-ipy}} from the ''community'' repository) and {{AUR|sepolgen}}.<br />
* Then install {{AUR|pambase-selinux}} and {{AUR|pam-selinux}} and make sure you can login again after the installation completed , because files in {{ic|/etc/pam.d/}} got removed and created when {{pkg|pambase}} got replaced with {{AUR|pambase-selinux}}.<br />
* Next you can install {{AUR|libcgroup}} and {{AUR|policycoreutils}}, before recompiling some core packages by installing: {{AUR|coreutils-selinux}}, {{AUR|findutils-selinux}}, {{AUR|iproute2-selinux}}, {{AUR|logrotate-selinux}}, {{AUR|openssh-selinux}}, {{AUR|psmisc-selinux}}, {{AUR|shadow-selinux}}, {{AUR|cronie-selinux}}<br />
* Next, backup your {{ic|/etc/sudoers}} file. Install {{AUR|sudo-selinux}} and restore your {{ic|/etc/sudoers}} (it is overridden when this package is installed as a replacement of {{pkg|sudo}}).<br />
* Next come util-linux and systemd. Because of a cyclic makedepends between these two packages which will not be fixed ({{bug|39767}}), you need to build the source package {{AUR|systemd-selinux}}, install {{AUR|libsystemd-selinux}}, build and install {{AUR|util-linux-selinux}} (with {{AUR|libutil-linux-selinux}}) and rebuild and install {{AUR|systemd-selinux}}.<br />
* Next, install {{AUR|dbus-selinux}}.<br />
<br />
After all these steps, you can install a SELinux kernel (like {{AUR|linux-selinux}}) and a policy (like {{AUR|selinux-refpolicy-arch}}).<br />
<br />
==== Using the GitHub repository ====<br />
<br />
All packages are maintained at https://github.com/archlinuxhardened/selinux . This repository also contains a script named {{ic|build_and_install_all.sh}} which builds and installs (or updates) all packages in the needed order. Here is an example of a way this script can be used in a user shell to install all packages (with downloading the GPG keys which are used to verify the source tarballs of the package):<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux<br />
./recv_gpg_keys.sh<br />
./build_and_install_all.sh<br />
<br />
Of course, it is possible to modify the content of {{ic|build_and_install_all.sh}} before running it, for example if you already have SELinux support in your kernel.<br />
<br />
===Changing boot loader configuration===<br />
<br />
If you have installed a new kernel, make sure that you update your bootloader accordingly to boot on it. Moreover you may need to add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to the kernel command line. More precisely, if the kernel configuration does not set {{ic|CONFIG_DEFAULT_SECURITY_SELINUX}}, {{ic|<nowiki>security=selinux</nowiki>}} is needed, and if it contains {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM=y</nowiki>}} {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0</nowiki>}}, {{ic|<nowiki>selinux=1</nowiki>}} is needed.<br />
<br />
====GRUB====<br />
<br />
Add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variable in {{ic|/etc/default/grub}}<br />
Run the following command:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
====Syslinux====<br />
<br />
Change your syslinux.cfg file by adding:<br />
<br />
{{hc|/boot/syslinux/syslinux.cfg|<nowiki>LABEL arch-selinux<br />
LINUX ../vmlinuz-linux-selinux<br />
APPEND root=/dev/sda2 ro security=selinux selinux=1<br />
INITRD ../initramfs-linux-selinux.img</nowiki>}}<br />
<br />
at the end. Change "linux-selinux" to whatever kernel you are using.<br />
<br />
====systemd-boot====<br />
<br />
Create a new loader entry, for example in {{ic|/boot/loader/entries/arch-selinux.conf}}:<br />
<br />
{{hc|/boot/loader/entries/arch-selinux.conf|2=<br />
title Arch Linux SELinux<br />
linux /vmlinuz-linux-selinux<br />
initrd /initramfs-linux-selinux.img<br />
options root=/dev/sda2 ro selinux=1 security=selinux<br />
}}<br />
<br />
===Checking PAM===<br />
<br />
A correctly set-up [[PAM]] is important to get the proper security context after login. Check for the presence of the following lines in {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{bc|# pam_selinux.so close should be the first session rule<br />
session required pam_selinux.so close}}<br />
<br />
{{bc|# pam_selinux.so open should only be followed by sessions to be executed in the user context<br />
session required pam_selinux.so open}}<br />
<br />
===Installing a policy===<br />
<br />
{{Warning|The reference policy as given by [http://oss.tresys.com/projects/refpolicy Tresys] is not very good for Arch Linux, as almost no file is labelled correctly. However, as of writing, Archers have no other choice. If anyone has made any significant strides in addressing this problem, they are encouraged to share it, preferably on the [[AUR]]. The major problems are:<br />
<br />
* {{ic|/lib}} and {{ic|/usr/lib}} are considered different (and also {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/bin}} and {{ic|/usr/sbin}}). This introduces some instability when applying labels to the whole system, as files in these folders may be seen with 2 (or 4) different labels. <br />
* systemd is not yet supported (C. PeBenito, main developer of the refpolicy, announced its willingness to work on it in its github repository in October 2014, http://oss.tresys.com/pipermail/refpolicy/2014-October/007430.html)}}<br />
<br />
Policies are the mainstay of SELinux. They are what govern its behaviour. The only policy currently available in the AUR is the Reference Policy. In order to install it, you should use the source files, which may be got from the package {{AUR|selinux-refpolicy-src}} or by downloading the latest release on https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease#current-release. When using the AUR package, navigate to {{ic|/etc/selinux/refpolicy/src/policy}} and run the following commands:<br />
<br />
{{bc|# make bare<br />
# make conf<br />
# make install}}<br />
<br />
to install the reference policy as it is. Those who know how to write SELinux policies can tweak them to their heart's content before running the commands written above. The command takes a while to do its job and taxes one core of your system completely, so do not worry. Just sit back and let the command run for as long as it takes.<br />
<br />
To load the reference policy run:<br />
{{bc|# make load}}<br />
<br />
Then, make the file {{ic|/etc/selinux/config}} with the following contents (Only works if you used the defaults as mentioned above. If you decided to change the name of the policy, you need to tweak the file):<br />
<br />
{{hc|/etc/selinux/config|<nowiki># This file controls the state of SELinux on the system.<br />
# SELINUX= can take one of these three values:<br />
# enforcing - SELinux security policy is enforced.<br />
# Set this value once you know for sure that SELinux is configured the way you like it and that your system is ready for deployment<br />
# permissive - SELinux prints warnings instead of enforcing.<br />
# Use this to customise your SELinux policies and booleans prior to deployment. Recommended during policy development.<br />
# disabled - No SELinux policy is loaded.<br />
# This is not a recommended setting, for it may cause problems with file labelling<br />
SELINUX=permissive<br />
# SELINUXTYPE= takes the name of SELinux policy to<br />
# be used. Current options are:<br />
# refpolicy (vanilla reference policy)<br />
# <custompolicy> - Substitute <custompolicy> with the name of any custom policy you choose to load<br />
SELINUXTYPE=refpolicy</nowiki>}}<br />
<br />
Now, you may reboot. After rebooting, run:<br />
<br />
# restorecon -r /<br />
<br />
to label your filesystem.<br />
<br />
Now, make a file {{ic|requiredmod.te}} with the contents:<br />
<br />
{{hc|requiredmod.te|<nowiki>module requiredmod 1.0;<br />
<br />
require {<br />
type devpts_t;<br />
type kernel_t;<br />
type device_t;<br />
type var_run_t;<br />
type udev_t;<br />
type hugetlbfs_t;<br />
type udev_tbl_t;<br />
type tmpfs_t;<br />
class sock_file write;<br />
class unix_stream_socket { read write ioctl };<br />
class capability2 block_suspend;<br />
class dir { write add_name };<br />
class filesystem associate;<br />
}<br />
<br />
#============= devpts_t ==============<br />
allow devpts_t device_t:filesystem associate;<br />
<br />
#============= hugetlbfs_t ==============<br />
allow hugetlbfs_t device_t:filesystem associate;<br />
<br />
#============= kernel_t ==============<br />
allow kernel_t self:capability2 block_suspend;<br />
<br />
#============= tmpfs_t ==============<br />
allow tmpfs_t device_t:filesystem associate;<br />
<br />
#============= udev_t ==============<br />
allow udev_t kernel_t:unix_stream_socket { read write ioctl };<br />
allow udev_t udev_tbl_t:dir { write add_name };<br />
allow udev_t var_run_t:sock_file write;</nowiki>}}<br />
<br />
and run the following commands:<br />
<br />
{{bc|<nowiki># checkmodule -m -o requiredmod.mod requiredmod.te<br />
# semodule_package -o requiredmod.pp -m requiredmod.mod<br />
# semodule -i requiredmod.pp</nowiki>}}<br />
<br />
This is required to remove a few messages from {{ic|/var/log/audit/audit.log}} which are a nuisance to deal with in the reference policy. This is an ugly hack and it should be made very clear that the policy so installed simply patches the reference policy in order to hide the effects of incorrect labelling.<br />
<br />
===Testing in a Vagrant virtual machine===<br />
<br />
It is possible to use [[Vagrant]] to provision a virtual Arch Linux machine with SELinux configured. This is a convenient way to test an Arch Linux system running SELinux without modifying a current system. Here are commands which can be used to achieve this:<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux/_vagrant<br />
vagrant up<br />
vagrant ssh<br />
<br />
==Post-installation steps==<br />
<br />
You can check that SELinux is working with {{ic|sestatus}}. You should get something like:<br />
<br />
{{bc|<nowiki>SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
SELinux root directory: /etc/selinux<br />
Loaded policy name: refpolicy<br />
Current mode: permissive<br />
Mode from config file: permissive<br />
Policy MLS status: disabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 28</nowiki>}}<br />
<br />
To maintain correct context, you can use ''restorecond'':<br />
<br />
# systemctl enable restorecond<br />
<br />
To switch to enforcing mode without rebooting, you can use:<br />
<br />
# echo 1 > /sys/fs/selinux/enforce<br />
<br />
===Swapfiles===<br />
<br />
If you have a swap file instead of a swap partition, issue the following commands in order to set the appropriate security context:<br />
<br />
{{bc|# semanage fcontext -a -t swapfile_t "/path/to/swapfile"<br />
# restorecon /path/to/swapfile}}<br />
<br />
==Working with SELinux==<br />
<br />
SELinux defines security using a different mechanism than traditional Unix access controls. The best way to understand it is by example. For example, the SELinux security context of the apache homepage looks like the following:<br />
<br />
$ls -lZ /var/www/html/index.html<br />
-rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html<br />
<br />
The first three and the last columns should be familiar to any (Arch) Linux user. The fourth column is new and has the format:<br />
<br />
user:role:type[:level]<br />
<br />
To explain:<br />
#'''User:''' The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br />
#'''Role:''' The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br />
#'''Type:''' When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br />
#'''Level:''' This optional field can also be know as a range and is only present if the policy supports MCS or MLS.<br />
<br />
This is important in case you wish to understand how to build your own policies, for these are the basic building blocks of SELinux. However, for most purposes, there is no need to, for the reference policy is sufficiently mature. However, if you are a power user or someone with very specific needs, then it might be ideal for you to learn how to make your own SELinux policies.<br />
<br />
[http://www.fosteringlinux.com/tag/selinux/ This] is a great series of articles for someone seeking to understand how to work with SELinux.<br />
<br />
==Troubleshooting==<br />
<br />
The place to look for SELinux errors is the systemd journal. In order to see SELinux messages related to the label {{ic|system_u:system_r:policykit_t:s0}} (for example), you would need to run:<br />
<br />
# journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0<br />
<br />
===Useful tools===<br />
<br />
There are some tools/commands that can greatly help with SELinux. <br />
<br />
;restorecon: Restores the context of a file/directory (or recursively with {{ic|-R}}) based on any policy rules <br />
;chcon: Change the context on a specific file<br />
<br />
===Reporting issues===<br />
<br />
Please report issues on GitHub: https://github.com/archlinuxhardened/selinux/issues<br />
<br />
==See also==<br />
*[[wikipedia:Security-Enhanced_Linux|Security Enhanced Linux]]<br />
*[http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml Gentoo SELinux Handbook]<br />
*[http://fedoraproject.org/wiki/SELinux Fedora Project's SELinux Wiki]<br />
*[http://www.nsa.gov/research/selinux/index.shtml NSA's Official SELinux Homepage]<br />
*[http://oss.tresys.com/projects/refpolicy Reference Policy Homepage]<br />
*[http://userspace.selinuxproject.org/trac/ SELinux Userspace Homepage]<br />
*[http://oss.tresys.com/projects/setools SETools Homepage]<br />
*[https://web.archive.org/web/20140816115906/http://jamesthebard.net/archlinux-selinux-and-you-a-trip-down-the-rabbit-hole/ ArchLinux, SELinux and You (archived)]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=SELinux&diff=476131SELinux2017-05-07T17:24:30Z<p>Thestinger: /* Current status in Arch Linux */ linux-hardened enables SELinux support, so the kernel portion is provided in the official repositories now with more to come (if people step up to help)</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:SELinux]]<br />
[[ru:SELinux]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|AppArmor}}<br />
{{Related articles end}}<br />
<br />
Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style mandatory access controls (MAC), through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.<br />
<br />
Running SELinux under a Linux distribution requires three things: An SELinux enabled kernel, SELinux Userspace tools and libraries, and SELinux Policies (mostly based on the Reference Policy). Some common Linux programs will also need to be patched/compiled with SELinux features.<br />
<br />
==Current status in Arch Linux==<br />
<br />
SELinux is not officially supported (see [https://lists.archlinux.org/pipermail/arch-general/2013-October/034352.html][https://lists.archlinux.org/pipermail/arch-general/2017-February/043149.html]). The status of unofficial support is:<br />
<br />
{| class="wikitable"<br />
! Name !! Status !! Available at<br />
|-<br />
| SELinux enabled kernel || Implemented for {{pkg|linux-hardened}}, but not {{pkg|linux}} || Removed since the 3.14 official {{pkg|linux}} kernel.<br />
|-<br />
| SELinux Userspace tools and libraries || Implemented in AUR: https://aur.archlinux.org/packages/?O=0&K=selinux || Work is done at https://github.com/archlinuxhardened/selinux<br />
|-<br />
| SELinux Policy || Work in progress, using [https://github.com/TresysTechnology/refpolicy Reference Policy] as upstream || Work in progress at https://github.com/archlinuxhardened/selinux-policy-arch/<br />
|}<br />
<br />
Summary of changes in AUR as compared to official core packages:<br />
<br />
{| class="wikitable"<br />
! Name !! Status and comments<br />
|-<br />
| linux || Need a rebuild with some KConfig options enabled<br />
|-<br />
| linux-hardened || Enabled<br />
|-<br />
| coreutils || Need a rebuild with {{ic|--with-selinux}} flag to link with libselinux<br />
|-<br />
| cronie || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| dbus || Need a rebuild with {{ic|--enable-libaudit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| findutils || Need a rebuild with libselinux installed to enable SELinux-specific options<br />
|-<br />
| iproute2 || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| logrotate || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| openssh || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| pam || Need a rebuild with {{ic|--enable-selinux}} flag for Linux-PAM ; Need a patch for pam_unix2, which only removes a function already implemented in a recent versions of libselinux<br />
|-<br />
| pambase || Configuration changes to add pam_selinux.so to {{ic|/etc/pam.d/system-login}}<br />
|-<br />
| psmisc || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| shadow || Need a rebuild with {{ic|--with-selinux}} flags<br />
|-<br />
| sudo || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| systemd || Need a rebuild with {{ic|--enable-audit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| util-linux || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
|}<br />
<br />
All of the other SELinux-related packages may be included without changes nor risks.<br />
<br />
==Concepts: Mandatory Access Controls==<br />
<br />
{{Note|This section is meant for beginners. If you know what SELinux does and how it works, feel free to skip ahead to the installation.}}<br />
<br />
Before you enable SELinux, it is worth understanding what it does. Simply and succinctly, SELinux enforces ''Mandatory Access Controls (MACs)'' on Linux. In contrast to SELinux, the traditional user/group/rwx permissions are a form of ''Discretionary Access Control (DAC)''. MACs are different from DACs because security policy and its execution are completely separated.<br />
<br />
An example would be the use of the ''sudo'' command. When DACs are enforced, sudo allows temporary privilege escalation to root, giving the process so spawned unrestricted systemwide access. However, when using MACs, if the security administrator deems the process to have access only to a certain set of files, then no matter what the kind of privilege escalation used, unless the security policy itself is changed, the process will remain constrained to simply that set of files. So if ''sudo'' is tried on a machine with SELinux running in order for a process to gain access to files its policy does not allow, it will fail.<br />
<br />
Another set of examples are the traditional (-rwxr-xr-x) type permissions given to files. When under DAC, these are user-modifiable. However, under MAC, a security administrator can choose to freeze the permissions of a certain file by which it would become impossible for any user to change these permissions until the policy regarding that file is changed.<br />
<br />
As you may imagine, this is particularly useful for processes which have the potential to be compromised, i.e. web servers and the like. If DACs are used, then there is a particularly good chance of havoc being wreaked by a compromised program which has access to privilege escalation.<br />
<br />
For further information, visit [[wikipedia:Mandatory access control]].<br />
<br />
==Installing SELinux==<br />
<br />
===Package description===<br />
<br />
All SELinux related packages belong to the ''selinux'' group in the AUR.<br />
<br />
====SELinux aware system utilities====<br />
<br />
;{{AUR|coreutils-selinux}}<br />
:Modified coreutils package compiled with SELinux support enabled. It replaces the {{pkg|coreutils}} package<br />
<br />
;{{AUR|ustr-selinux}}<br />
:Patched ustr package needed only to build {{AUR|libsemanage}}. It replaces the {{pkg|ustr}} package, which does not work with recent gcc ({{bug|46445}}).<br />
<br />
;{{AUR|pam-selinux}} and {{AUR|pambase-selinux}}<br />
:PAM package with pam_selinux.so. and the underlying base package. They replace the {{pkg|pam}} and {{pkg|pambase}} packages respectively.<br />
<br />
;{{AUR|util-linux-selinux}}<br />
:Modified util-linux package compiled with SELinux support enabled. It replaces the {{pkg|util-linux}} package.<br />
<br />
;{{AUR|systemd-selinux}}<br />
:An SELinux aware version of [[Systemd]]. It replaces the {{pkg|systemd}} package.<br />
<br />
;{{AUR|dbus-selinux}}<br />
:An SELinux aware version of [[D-Bus]]. It replaces the {{pkg|dbus}} package.<br />
<br />
;{{AUR|findutils-selinux}}<br />
:Patched findutils package compiled with SELinux support to make searching of files with specified security context possible. It replaces the {{pkg|findutils}} package.<br />
<br />
;{{AUR|iproute2-selinux}}<br />
:iproute2 package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|ss}}. It replaces the {{pkg|iproute2}} package.<br />
<br />
;{{AUR|psmisc-selinux}}<br />
:Psmisc package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|killall}}. It replaces the {{pkg|psmisc}} package.<br />
<br />
;{{AUR|shadow-selinux}}<br />
:Shadow package compiled with SELinux support; contains a modified {{ic|/etc/pam.d/login}} file to set correct security context for user after login. It replaces the {{pkg|shadow}} package.<br />
<br />
;{{AUR|sudo-selinux}}<br />
:Modified [[sudo]] package compiled with SELinux support which sets the security context correctly. It replaces the {{pkg|sudo}} package.<br />
<br />
;{{AUR|cronie-selinux}}<br />
:Fedora fork of Vixie cron with SELinux enabled. It replaces the {{pkg|cronie}} package.<br />
<br />
;{{AUR|logrotate-selinux}}<br />
:Logrotate package compiled with SELinux support. It replaces the {{pkg|logrotate}} package.<br />
<br />
;{{AUR|openssh-selinux}}<br />
:[[OpenSSH]] package compiled with SELinux support to set security context for user sessions. It replaces the {{pkg|openssh}} package.<br />
<br />
====SELinux userspace utilities====<br />
;{{AUR|checkpolicy}}<br />
:Tools to build SELinux policy<br />
<br />
;{{AUR|libselinux}}<br />
:Library for security-aware applications. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsemanage}}<br />
:Library for policy management. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsepol}}<br />
:Library for binary policy manipulation.<br />
<br />
;{{AUR|policycoreutils}}<br />
:SELinux core utils such as newrole, setfiles, etc.<br />
<br />
;{{AUR|sepolgen}}<br />
:A Python library for parsing and modifying policy source.<br />
<br />
====SELinux policy packages====<br />
<br />
;{{AUR|selinux-refpolicy-src}}<br />
:Reference policy sources<br />
<br />
;{{AUR|selinux-refpolicy-arch}}<br />
:Precompiled modular Reference policy with headers and documentation but without sources. Development Arch Linux Refpolicy patches included, which fixes issues related to path labeling and systemd support. These patches are also sent to Reference Policy maintainers and their inclusion in {{AUR|selinux-refpolicy-arch}} is mainly a way to perform updates between Refpolicy releases.<br />
<br />
====Other SELinux tools====<br />
<br />
;{{AUR|setools}}<br />
:CLI and GUI tools to manage SELinux<br />
<br />
=== Installation ===<br />
<br />
===Preparing the Kernel===<br />
<br />
Only ext2, ext3, ext4, JFS, XFS and BtrFS filesystems are supported to use SELinux. By default, the Arch Kernel does not have the SELinux LSM enabled. If you are using Arch Linux packaged kernel ({{pkg|linux}}), there is an AUR package which adds the configuration options for SELinux, {{aur|linux-selinux}}. Otherwise, when you are using a custom kernel, please do make sure that Xattr (Extended Attributes), {{ic|CONFIG_AUDIT}} and {{ic|CONFIG_SECURITY_SELINUX}} are enabled in your config. (Source: [http://wiki.debian.org/SELinux/Setup#kernel Debian Wiki])<br />
<br />
Here is the complete list of options which need to be enabled on Linux 4.3.3 to use SELinux :<br />
{{hc|config.selinux-custom|<nowiki>CONFIG_AUDIT=y<br />
CONFIG_AUDITSYSCALL=y<br />
CONFIG_AUDIT_WATCH=y<br />
CONFIG_AUDIT_TREE=y<br />
CONFIG_NETLABEL=y<br />
CONFIG_IP_NF_SECURITY=m<br />
CONFIG_IP6_NF_SECURITY=m<br />
CONFIG_NETFILTER_XT_TARGET_AUDIT=m<br />
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y<br />
CONFIG_NFSD_V4_SECURITY_LABEL=y<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_PATH=y<br />
CONFIG_LSM_MMAP_MIN_ADDR=65536<br />
CONFIG_SECURITY_SELINUX=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM=y<br />
CONFIG_SECURITY_SELINUX_DISABLE=y<br />
CONFIG_SECURITY_SELINUX_DEVELOP=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1<br />
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1<br />
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y<br />
CONFIG_SECURITY_SELINUX_AVC_STATS=y<br />
CONFIG_DEFAULT_SECURITY_SELINUX=y</nowiki>}}<br />
<br />
{{Note|If using proprietary drivers, such as [[NVIDIA]] graphics drivers, you may need to [[NVIDIA#Custom kernel|rebuild them]].}}<br />
<br />
There are two methods to install the requisite SELinux packages.<br />
<br />
==== Via AUR ====<br />
<br />
* First, install SELinux userspace tools and libraries, in this order (because of the dependencies): {{AUR|libsepol}}, {{AUR|libselinux}}, {{AUR|checkpolicy}}, {{AUR|setools}}, {{AUR|ustr-selinux}}, {{AUR|libsemanage}} (which needs {{pkg|python2-ipy}} from the ''community'' repository) and {{AUR|sepolgen}}.<br />
* Then install {{AUR|pambase-selinux}} and {{AUR|pam-selinux}} and make sure you can login again after the installation completed , because files in {{ic|/etc/pam.d/}} got removed and created when {{pkg|pambase}} got replaced with {{AUR|pambase-selinux}}.<br />
* Next you can install {{AUR|libcgroup}} and {{AUR|policycoreutils}}, before recompiling some core packages by installing: {{AUR|coreutils-selinux}}, {{AUR|findutils-selinux}}, {{AUR|iproute2-selinux}}, {{AUR|logrotate-selinux}}, {{AUR|openssh-selinux}}, {{AUR|psmisc-selinux}}, {{AUR|shadow-selinux}}, {{AUR|cronie-selinux}}<br />
* Next, backup your {{ic|/etc/sudoers}} file. Install {{AUR|sudo-selinux}} and restore your {{ic|/etc/sudoers}} (it is overridden when this package is installed as a replacement of {{pkg|sudo}}).<br />
* Next come util-linux and systemd. Because of a cyclic makedepends between these two packages which will not be fixed ({{bug|39767}}), you need to build the source package {{AUR|systemd-selinux}}, install {{AUR|libsystemd-selinux}}, build and install {{AUR|util-linux-selinux}} (with {{AUR|libutil-linux-selinux}}) and rebuild and install {{AUR|systemd-selinux}}.<br />
* Next, install {{AUR|dbus-selinux}}.<br />
<br />
After all these steps, you can install a SELinux kernel (like {{AUR|linux-selinux}}) and a policy (like {{AUR|selinux-refpolicy-arch}}).<br />
<br />
==== Using the GitHub repository ====<br />
<br />
All packages are maintained at https://github.com/archlinuxhardened/selinux . This repository also contains a script named {{ic|build_and_install_all.sh}} which builds and installs (or updates) all packages in the needed order. Here is an example of a way this script can be used in a user shell to install all packages (with downloading the GPG keys which are used to verify the source tarballs of the package):<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux<br />
./recv_gpg_keys.sh<br />
./build_and_install_all.sh<br />
<br />
Of course, it is possible to modify the content of {{ic|build_and_install_all.sh}} before running it, for example if you already have SELinux support in your kernel.<br />
<br />
===Changing boot loader configuration===<br />
<br />
If you have installed a new kernel, make sure that you update your bootloader accordingly to boot on it. Moreover you may need to add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to the kernel command line. More precisely, if the kernel configuration does not set {{ic|CONFIG_DEFAULT_SECURITY_SELINUX}}, {{ic|<nowiki>security=selinux</nowiki>}} is needed, and if it contains {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM=y</nowiki>}} {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0</nowiki>}}, {{ic|<nowiki>selinux=1</nowiki>}} is needed.<br />
<br />
====GRUB====<br />
<br />
Add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variable in {{ic|/etc/default/grub}}<br />
Run the following command:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
====Syslinux====<br />
<br />
Change your syslinux.cfg file by adding:<br />
<br />
{{hc|/boot/syslinux/syslinux.cfg|<nowiki>LABEL arch-selinux<br />
LINUX ../vmlinuz-linux-selinux<br />
APPEND root=/dev/sda2 ro security=selinux selinux=1<br />
INITRD ../initramfs-linux-selinux.img</nowiki>}}<br />
<br />
at the end. Change "linux-selinux" to whatever kernel you are using.<br />
<br />
====systemd-boot====<br />
<br />
Create a new loader entry, for example in {{ic|/boot/loader/entries/arch-selinux.conf}}:<br />
<br />
{{hc|/boot/loader/entries/arch-selinux.conf|2=<br />
title Arch Linux SELinux<br />
linux /vmlinuz-linux-selinux<br />
initrd /initramfs-linux-selinux.img<br />
options root=/dev/sda2 ro selinux=1 security=selinux<br />
}}<br />
<br />
===Checking PAM===<br />
<br />
A correctly set-up [[PAM]] is important to get the proper security context after login. Check for the presence of the following lines in {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{bc|# pam_selinux.so close should be the first session rule<br />
session required pam_selinux.so close}}<br />
<br />
{{bc|# pam_selinux.so open should only be followed by sessions to be executed in the user context<br />
session required pam_selinux.so open}}<br />
<br />
===Installing a policy===<br />
<br />
{{Warning|The reference policy as given by [http://oss.tresys.com/projects/refpolicy Tresys] is not very good for Arch Linux, as almost no file is labelled correctly. However, as of writing, Archers have no other choice. If anyone has made any significant strides in addressing this problem, they are encouraged to share it, preferably on the [[AUR]]. The major problems are:<br />
<br />
* {{ic|/lib}} and {{ic|/usr/lib}} are considered different (and also {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/bin}} and {{ic|/usr/sbin}}). This introduces some instability when applying labels to the whole system, as files in these folders may be seen with 2 (or 4) different labels. <br />
* systemd is not yet supported (C. PeBenito, main developer of the refpolicy, announced its willingness to work on it in its github repository in October 2014, http://oss.tresys.com/pipermail/refpolicy/2014-October/007430.html)}}<br />
<br />
Policies are the mainstay of SELinux. They are what govern its behaviour. The only policy currently available in the AUR is the Reference Policy. In order to install it, you should use the source files, which may be got from the package {{AUR|selinux-refpolicy-src}} or by downloading the latest release on https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease#current-release. When using the AUR package, navigate to {{ic|/etc/selinux/refpolicy/src/policy}} and run the following commands:<br />
<br />
{{bc|# make bare<br />
# make conf<br />
# make install}}<br />
<br />
to install the reference policy as it is. Those who know how to write SELinux policies can tweak them to their heart's content before running the commands written above. The command takes a while to do its job and taxes one core of your system completely, so do not worry. Just sit back and let the command run for as long as it takes.<br />
<br />
To load the reference policy run:<br />
{{bc|# make load}}<br />
<br />
Then, make the file {{ic|/etc/selinux/config}} with the following contents (Only works if you used the defaults as mentioned above. If you decided to change the name of the policy, you need to tweak the file):<br />
<br />
{{hc|/etc/selinux/config|<nowiki># This file controls the state of SELinux on the system.<br />
# SELINUX= can take one of these three values:<br />
# enforcing - SELinux security policy is enforced.<br />
# Set this value once you know for sure that SELinux is configured the way you like it and that your system is ready for deployment<br />
# permissive - SELinux prints warnings instead of enforcing.<br />
# Use this to customise your SELinux policies and booleans prior to deployment. Recommended during policy development.<br />
# disabled - No SELinux policy is loaded.<br />
# This is not a recommended setting, for it may cause problems with file labelling<br />
SELINUX=permissive<br />
# SELINUXTYPE= takes the name of SELinux policy to<br />
# be used. Current options are:<br />
# refpolicy (vanilla reference policy)<br />
# <custompolicy> - Substitute <custompolicy> with the name of any custom policy you choose to load<br />
SELINUXTYPE=refpolicy</nowiki>}}<br />
<br />
Now, you may reboot. After rebooting, run:<br />
<br />
# restorecon -r /<br />
<br />
to label your filesystem.<br />
<br />
Now, make a file {{ic|requiredmod.te}} with the contents:<br />
<br />
{{hc|requiredmod.te|<nowiki>module requiredmod 1.0;<br />
<br />
require {<br />
type devpts_t;<br />
type kernel_t;<br />
type device_t;<br />
type var_run_t;<br />
type udev_t;<br />
type hugetlbfs_t;<br />
type udev_tbl_t;<br />
type tmpfs_t;<br />
class sock_file write;<br />
class unix_stream_socket { read write ioctl };<br />
class capability2 block_suspend;<br />
class dir { write add_name };<br />
class filesystem associate;<br />
}<br />
<br />
#============= devpts_t ==============<br />
allow devpts_t device_t:filesystem associate;<br />
<br />
#============= hugetlbfs_t ==============<br />
allow hugetlbfs_t device_t:filesystem associate;<br />
<br />
#============= kernel_t ==============<br />
allow kernel_t self:capability2 block_suspend;<br />
<br />
#============= tmpfs_t ==============<br />
allow tmpfs_t device_t:filesystem associate;<br />
<br />
#============= udev_t ==============<br />
allow udev_t kernel_t:unix_stream_socket { read write ioctl };<br />
allow udev_t udev_tbl_t:dir { write add_name };<br />
allow udev_t var_run_t:sock_file write;</nowiki>}}<br />
<br />
and run the following commands:<br />
<br />
{{bc|<nowiki># checkmodule -m -o requiredmod.mod requiredmod.te<br />
# semodule_package -o requiredmod.pp -m requiredmod.mod<br />
# semodule -i requiredmod.pp</nowiki>}}<br />
<br />
This is required to remove a few messages from {{ic|/var/log/audit/audit.log}} which are a nuisance to deal with in the reference policy. This is an ugly hack and it should be made very clear that the policy so installed simply patches the reference policy in order to hide the effects of incorrect labelling.<br />
<br />
===Testing in a Vagrant virtual machine===<br />
<br />
It is possible to use [[Vagrant]] to provision a virtual Arch Linux machine with SELinux configured. This is a convenient way to test an Arch Linux system running SELinux without modifying a current system. Here are commands which can be used to achieve this:<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux/_vagrant<br />
vagrant up<br />
vagrant ssh<br />
<br />
==Post-installation steps==<br />
<br />
You can check that SELinux is working with {{ic|sestatus}}. You should get something like:<br />
<br />
{{bc|<nowiki>SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
SELinux root directory: /etc/selinux<br />
Loaded policy name: refpolicy<br />
Current mode: permissive<br />
Mode from config file: permissive<br />
Policy MLS status: disabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 28</nowiki>}}<br />
<br />
To maintain correct context, you can use ''restorecond'':<br />
<br />
# systemctl enable restorecond<br />
<br />
To switch to enforcing mode without rebooting, you can use:<br />
<br />
# echo 1 > /sys/fs/selinux/enforce<br />
<br />
===Swapfiles===<br />
<br />
If you have a swap file instead of a swap partition, issue the following commands in order to set the appropriate security context:<br />
<br />
{{bc|# semanage fcontext -a -t swapfile_t "/path/to/swapfile"<br />
# restorecon /path/to/swapfile}}<br />
<br />
==Working with SELinux==<br />
<br />
SELinux defines security using a different mechanism than traditional Unix access controls. The best way to understand it is by example. For example, the SELinux security context of the apache homepage looks like the following:<br />
<br />
$ls -lZ /var/www/html/index.html<br />
-rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html<br />
<br />
The first three and the last columns should be familiar to any (Arch) Linux user. The fourth column is new and has the format:<br />
<br />
user:role:type[:level]<br />
<br />
To explain:<br />
#'''User:''' The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br />
#'''Role:''' The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br />
#'''Type:''' When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br />
#'''Level:''' This optional field can also be know as a range and is only present if the policy supports MCS or MLS.<br />
<br />
This is important in case you wish to understand how to build your own policies, for these are the basic building blocks of SELinux. However, for most purposes, there is no need to, for the reference policy is sufficiently mature. However, if you are a power user or someone with very specific needs, then it might be ideal for you to learn how to make your own SELinux policies.<br />
<br />
[http://www.fosteringlinux.com/tag/selinux/ This] is a great series of articles for someone seeking to understand how to work with SELinux.<br />
<br />
==Troubleshooting==<br />
<br />
The place to look for SELinux errors is the systemd journal. In order to see SELinux messages related to the label {{ic|system_u:system_r:policykit_t:s0}} (for example), you would need to run:<br />
<br />
# journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0<br />
<br />
===Useful tools===<br />
<br />
There are some tools/commands that can greatly help with SELinux. <br />
<br />
;restorecon: Restores the context of a file/directory (or recursively with {{ic|-R}}) based on any policy rules <br />
;chcon: Change the context on a specific file<br />
<br />
===Reporting issues===<br />
<br />
Please report issues on GitHub: https://github.com/archlinuxhardened/selinux/issues<br />
<br />
==See also==<br />
*[[wikipedia:Security-Enhanced_Linux|Security Enhanced Linux]]<br />
*[http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml Gentoo SELinux Handbook]<br />
*[http://fedoraproject.org/wiki/SELinux Fedora Project's SELinux Wiki]<br />
*[http://www.nsa.gov/research/selinux/index.shtml NSA's Official SELinux Homepage]<br />
*[http://oss.tresys.com/projects/refpolicy Reference Policy Homepage]<br />
*[http://userspace.selinuxproject.org/trac/ SELinux Userspace Homepage]<br />
*[http://oss.tresys.com/projects/setools SETools Homepage]<br />
*[https://web.archive.org/web/20140816115906/http://jamesthebard.net/archlinux-selinux-and-you-a-trip-down-the-rabbit-hole/ ArchLinux, SELinux and You (archived)]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Paxd&diff=476130Paxd2017-05-07T17:14:37Z<p>Thestinger: redirect to SELinux since it's the closest and only fit for replacing this...</p>
<hr />
<div>#REDIRECT [[SELinux]]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=PAX&diff=476129PAX2017-05-07T17:14:07Z<p>Thestinger: redirect to Security#Kernel hardening</p>
<hr />
<div>#REDIRECT [[Security#Kernel hardening]]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Pax&diff=476128Pax2017-05-07T17:13:55Z<p>Thestinger: redirect to Security#Kernel hardening</p>
<hr />
<div>#REDIRECT [[Security#Kernel hardening]]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=RBAC&diff=476127RBAC2017-05-07T17:13:11Z<p>Thestinger: redirect to Security#Mandatory access control</p>
<hr />
<div>#REDIRECT [[Security#Mandatory access control]]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=RBAC&diff=476126RBAC2017-05-07T17:12:30Z<p>Thestinger: redirect to Security#Kernel hardening</p>
<hr />
<div>#REDIRECT [[Security#Kernel hardening]]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Linux-grsec&diff=476125Linux-grsec2017-05-07T17:12:24Z<p>Thestinger: redirect to Security#Kernel hardening</p>
<hr />
<div>#REDIRECT [[Security#Kernel hardening]]</div>Thestingerhttps://wiki.archlinux.org/index.php?title=Grsecurity_Patchset&diff=476124Grsecurity Patchset2017-05-07T17:12:18Z<p>Thestinger: redirect to Security#Kernel hardening</p>
<hr />
<div>#REDIRECT [[Security#Kernel hardening]]</div>Thestinger