From ArchWiki
Jump to navigation Jump to search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.

Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어

External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

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

Reason: please use the first argument of the template to provide a brief explanation. (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.



Best way is to set password on changing boot parameters. Add the following to /boot/grub/grub.cfg (assume login is “master” and password “retsam”):

set superusers="master"
password master retsam

Don’t forget to set 600 permissions on grub.cfg!


To ensure that no one just walks up to your computer and presses CTRL-ALT-DEL to restart your machine, you can disable the capture of CTRL-ALT-DEL in the file /etc/inittab. I could see this being used in a production environment, where the operator needs to use the keyboard but the computer itself is locked away.

Open the file /etc/inittab and find the line

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

comment out the line by inserting a leading #. This change will not take effect until you restart or issue the command

# /sbin/init -q

Of course if someone has physical access to your machine he could just press the power button to shutdown the machine!

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

here is example script, that can be placed to eg.: /etc/profile.d/

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, than you can use just:

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

Note that this will not work if there's some command running in the bash (eg.: some 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.


Any directories writable by a regular user should be mounted separately from / to avoid hardlink vulnerabilities and Denial of Service attacks (quotas do not stop a user from causing a DoS if there are world-writable directories).

Absolute minimum partition layout for a secure system:

  • /
  • /var: /var/spool/mail, /var/lock and /var/tmp are world writable, also, logging can be used by an attacker to fill the partition
  • /tmp: world writable
  • /home: writable by regular users
Note: /tmp can be mounted as tmpfs, so you do not need to create a partition for it.

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

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

You should know that encryption is the only way for protecting your data against people that have physical access to your computer. But once you mount an encrypted volume you have to be sure that you are the only person having physical or root access to the machine (nothing in the system is safe against root).

User setup

After installation make a normal user for daily use. Don’t use the root user for daily use! Pick a secure password. I trust you know 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, like me, 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.

Restricting su

See su#Security for details.

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 changing the file /etc/securetty and commenting out the tty lines. All you have to do is change




Repeat for any tty you wish to block. To check the effect of this change, start by commenting out only one line. Then goto 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 change the file /etc/pam.d/login. Find the line that reads

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

and remove the leading #. Then find the line that reads

auth required onerr=succeed file=/var/log/faillog

and insert a leading # on the line. If you don’t do this, then every failed login attempt will be counted twice. That’s all there is to it. If you feel adventures, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually use the following command as root

[root@localhost] pam_tally --user --reset

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

Use sudo for system commands

To make a user run some system commands as root it is advisable to use sudo to give that user the needed authority. It wouldn’t be good to hand out the root password to just anyone. Even if you are the only user on the system, using sudo is a good idea to keep from using a root console too much. Sometimes you just forget to logout again!

Setting up sudo is quite easy. Just use the visudo command to bring up the configuration file in the editor. The file already includes some examples you can use. I will show you one command that I always add to my sudoers file. I want to be able to mount samba shares from my server on my workstation with a regular user, so I add the following using visudo

%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). If you’re not comfortable with using the vi style editor, you can use the following to use nano instead.

[root@localhost] EDITOR=nano visudo

The above is not correct security wise. See following paragraph for explanation.

By default, visudo doesn’t follow EDITOR envvar. Also it’s regarded as severe security risk since everything can be used as EDITOR (hello, rootkits!). However, sudo from the core repository is compiled with --with-env-editor and honors the use of the VISUAL and EDITOR variables.

The best practice is to add the following line to /etc/sudoers (remember to put full path to your favourite editor):

Defaults editor=/usr/bin/nano

Don’t forget to use only visudo for this!

Please be careful not to enable the line that gives the user power over all commands! Only few commands should be made available to run as root via sudo.

Password hashes

Consider switching from MD5 hashes to SHA password hashes to make it near impossible for someone to reverse the hashes into your plaintext passwords.

Access control


TCP/IP stack hardening

TCP/IP stack hardening

Kernel hardening


Authenticating Updates

See pacman-key.

Note: Before pacman 4, package checking was done through paccheckAUR [1] which is now deprecated and no longer maintained.