Difference between revisions of "Security"

From ArchWiki
Jump to: navigation, search
(Editing files: Adds section on rvim to section 'Use sudo instead of su')
m (Editing files: Fixes broken equals sign in code block (d'oh!))
Line 146: Line 146:
to your shell's configuration file and use `sudoedit filename` or `sudo -e filename` to edit files. This will automatically edit `filename` with `rvim`, disabling shell commands from within your text editor.
to your shell's configuration file and use `sudoedit filename` or `sudo -e filename` to edit files. This will automatically edit `filename` with `rvim`, disabling shell commands from within your text editor.

Revision as of 04:32, 30 June 2013

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Many of these categories are just links, or lists of links. Some of the language is repetitive or unclear. (Discuss in Talk:Security#)

Instructions on how to harden and secure an Arch Linux system.


  • It is possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.
  • There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. 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.
  • Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!
  • Principle of least privilege

Physical security

Note: You can ignore this section if you just want to secure your computer against remote threats.

Physical access to a computer is basically root access, but you can stop an attacker from having access without removing your hard drive (also see #Disk encryption) or resetting your BIOS settings (both of which involve opening the computer).

Locking down BIOS

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.

Bootloader password

It's highly important to protect your bootloader. There's a magic kernel parameter called init=/bin/sh. This makes any user/login restrictions totally useless.

Good (strong) passwords can be obtained with ease, through the use of the apg package, or Automated Password Generator.


See: GRUB#Security

Automatic logout on VCs (and SSH)

If you are using Bash or Zsh, you can set TMOUT, so you will never forget open shell on VC (where xscreensaver is not protecting you):

TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
	/dev/tty[0-9]*) export TMOUT;;

if you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:

$ export TMOUT="$(( 60*10 ))";

Note that this will not work if there's some command running in the shell (eg.: an SSH session or other shell without TMOUT support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.


The kernel now prevents security issues related to hardlinks and symlinks if the fs.protected_hardlinks and fs.protected_symlinks sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.

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 /var or /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).

Mount options

Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).

Relevant mount options

  • nodev: Do not interpret character or block special devices on the file system.
  • nosuid: Do not allow set-user-identifier or set-group-identifier bits to take effect.
  • noexec: Do not allow direct execution of any binaries on the mounted filesystem.

Potential usage

Note: Data partitions should always be mounted with nodev, nosuid, noexec.
Partition nodev nosuid noexec
/var yes yes yes [1]
/home yes yes yes, if you do not code or use wine
/dev/shm yes yes yes
/tmp yes yes maybe, breaks compiling packages and various other things
/boot yes yes yes

[1] Note that some packages (building nvidia-dkmsAUR for example) may require exec on /var.

Filesystem permissions

The default filesystem 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 http or nobody users.

For example:

# chmod 700 /boot /etc/{iptables,arptables}

Disk encryption

Disk Encryption, preferably full disk encryption with a 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.

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.

Certain programs, like TrueCrypt, allow the user to encrypt a single file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure. Hidden volumes create another layer of security, introducing plausible deniability for encrypted data.

User setup

After installation make a normal user for daily use. Don't use the root user for daily use. Pick a secure password. Do not to use a dictionary word or something like your dog's name. A password should be at least eight characters long. Contain a mix of upper and lower case letters. It should include at least one number and/or one special character.

If you have a good memory for passwords then you can use a program like pwgen to create a bunch of passwords and print them on the screen. Then just pick one to use. Alternately you can make a password using the first characters from every word in a sentence. Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you don't mind typing you could make it “The girl is walking down the rainy street.”

Use sudo instead of su

Using sudo for privileged access is preferable to su for a number of reasons.

  • It keeps a log of which normal privilege user has run each privileged command.
  • The root user password need not be given out to each user who requires root access.
  • 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 principle of least privilege.
  • 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:
# visudo
alice ALL = NOPASSWD: /path/to/program

Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

This allows all users who are members of the group users to run the commands /sbin/mount.cifs and /sbin/umount.cifs from any machine (ALL).

Tip: To use nano instead of vi with visudo,
Defaults editor=/usr/bin/nano

Exporting # EDITOR=nano visudo is regarded as a severe security risk since everything can be used as an EDITOR.

Editing files

Using a text editor like `vim` as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add


to your shell's configuration file and use `sudoedit filename` or `sudo -e filename` to edit files. This will automatically edit `filename` with `rvim`, disabling shell commands from within your text editor.

No root login at the console

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 user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only need to guess a password. Blocking root login at the console is done by commenting out the tty lines in /etc/securetty.


Repeat for any tty you wish to block. 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 "Login incorrect". Now that we're sure it works, go back and comment out the rest of the tty lines.

Lockout user after three failed login attempts

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. To lockout a user for ten minutes after three failed login attempts you have to modify /etc/pam.d/system-login:

auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
#auth required pam_tally.so onerr=succeed file=/var/log/faillog

If you don't comment the second line every failed login attempt will be counted twice. That's all there's 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:

# pam_tally --user --reset

If you want to permanently lockout a user after 3 failed login attempts remove the unlock_time part of the line. The user can then not login until root unlocks the account.

Password hashes

The default Arch hash sha512 is very strong and there's no need to change it.

Access control


TCP/IP stack hardening

TCP/IP stack hardening

Kernel hardening


Authenticating packages

Package signing is enabled (and required) by default and relies on a web of trust from 5 trusted master keys. See pacman-key for details.

See also