Difference between revisions of "Securing Arch Linux"

From ArchWiki
Jump to: navigation, search
m (fixed note and added suggestion to move page so that "Arch Linux" can be capitalized in name)
Line 2: Line 2:
[[Category:Networking (English)]]
[[Category:Networking (English)]]
[[Category:HOWTOs (English)]]
[[Category:HOWTOs (English)]]
{{moveto|Securing Arch Linux}}
== Foreword ==
== Foreword ==
Line 166: Line 167:
* use (enhanced?) ACL on partitions
* use (enhanced?) ACL on partitions
'''NOTE:''' This guide was originally intended for the Arch Linux Magazine. It ''was'' published on rollingrelease.com, and there it was suggested to make a wiki page out of it. Some of the info here is taken from the comments on rollingrelease.com
{{Note|This guide was originally intended for the Arch Linux Magazine. It ''was'' published on rollingrelease.com, and there it was suggested to make a wiki page out of it. Some of the info here is taken from the comments on rollingrelease.com}}

Revision as of 23:37, 22 November 2010



The first question you have to ask yourself is: How paranoid are you?
It is possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it. The first step actually already starts before you install the system. You should take a minute to consider your partition layout.

Partition setup

Separate partitions for /var, /tmp, /home and any other user data you may have would be a good idea. Keeping /var and /tmp on separate partitions will make sure your system does not stop responding due to /var or /tmp filling up your root partition. Additionally the partitions should be mounted with the option NOEXEC (this ensures that the execute bit is disabled on any binary files on the partition) and NOSUID (this disables the SUID/SGID file-attribute on the partition).

Please note that some programs may stop working when NOEXEC is used. If you should indeed need to run a program from a data partition, a workaround could be to use a script to remount the partition with the option EXEC. Then perform the desired task and then remount the partition with the option NOEXEC again. Please see following example:

mount -o remount,exec /tmp
mount -o remount,noexec /tmp

Data partitions should always be mounted with option NOEXEC and NOSUID, as there should never be the need for a program to run from such a partition. And especially not with root privileges! If you don’t plan to install any programs in your home folder, you can also set NOEXEC on the /home partition. NOSUID should always be set on /home.

Please note that programs like crossover-office and eagle-cad, when installed directly from the downloaded run file, will install in the home directory. Setting the NOEXEC option on the partition would of course keep those programs from running.

Filesystem protection

It would also be a real good idea to change default directory permissions to something like the following:

chmod 700 boot/
chmod 711 dev/
chmod 711 etc/
chmod 711 home/
chmod 700 /home/*
chmod 700 media/
chmod 700 mnt/
chmod 700 opt/
chmod 700 root/
chmod 700 srv/
chmod 700 sys/
chmod 700 usr/
chmod 1733 tmp/
chmod 711 var
chmod 711 /var/log
chmod 711 /var/mail
chmod 1733 /var/tmp

And set also /bin and /proc (711) but it's a choice to let users have completion (for instance) and see their processes.

This would have to be checked each time an update is performed, as updating the filesystem package would change these permissions back to default again.

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

This is actually mostly necessary on a multiuser system, but is considered good practice security wise. Restricting the users who can su to root is done by changing the file /etc/pam.d/su. Find the line that reads

#auth required pam_wheel.so use_uid

and remove the leading #. Of course you need to make sure that your user is a member of the wheel group before you apply this change, else you will not be able to use SU to gain root privileges!

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 pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog

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

auth required pam_tally.so 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.


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

[root@localhost] /sbin/init -q

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

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

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

Best way is to set password on changing boot parameters. In GRUB, 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! You can do this also in LILO, read the manual for instructions.


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!


Some resources that might be of interest to you


  • Set BIOS password to keep user from booting removable media.
  • Encryption
  • base64 /dev/urandom | dd bs=1 count=10 2>/dev/null
  • Change to use SHA passwords
  • Fail2ban
  • SElinux / AppArmor
  • use (enhanced?) ACL on partitions
Note: This guide was originally intended for the Arch Linux Magazine. It was published on rollingrelease.com, and there it was suggested to make a wiki page out of it. Some of the info here is taken from the comments on rollingrelease.com