https://wiki.archlinux.org/api.php?action=feedcontributions&user=Phil.r.dubois&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:18:12ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Xrdp&diff=653813Xrdp2021-03-02T02:22:45Z<p>Phil.r.dubois: /* Troubleshooting */ Added mention to add DE parameter to .xrdpinitrc</p>
<hr />
<div>[[Category:Remote desktop]]<br />
[[ja:Xrdp]]<br />
'''xrdp''' is a daemon that supports Microsoft's [[Wikipedia:Remote Desktop Protocol|Remote Desktop Protocol]] (RDP).<br />
It uses Xvnc, X11rdp or xorgxrdp as a backend.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|xrdp}} package (or alternatively {{AUR|xrdp-git}} for the development version).<br />
<br />
=== Autoboot at startup ===<br />
The {{AUR|xrdp}} package contains service files for systemd. [[Enable]] {{ic|xrdp.service}} and {{ic|xrdp-sesman.service}}.<br />
<br />
=== Running as Terminal Server (Xorg) ===<br />
[[Install]] the {{AUR|xorgxrdp-git}} package.<br />
<br />
Add {{ic|1=allowed_users=anybody}} to {{ic|/etc/X11/Xwrapper.config}} to allow anybody to start X<br />
<br />
Edit {{ic|~/.xinitrc}} or {{ic|/etc/X11/xinit/xinitrc}} to launch your DE.<br />
<br />
==== Troubleshooting ====<br />
* If you encounter black box around mouse pointer create {{ic|~/.Xresources-xrdp}} with line {{ic|Xcursor.core:1}} and load it in {{ic|~/.xinitrc}} like<br />
<br />
{{bc|<nowiki><br />
xrdb ~/.Xresources-xrdp<br />
exec startlxde<br />
</nowiki>}}<br />
<br />
You may need to install {{pkg|xorg-xrdb}}.<br />
<br />
<br />
* You may get a black screen after logging into the session manager if your {{ic|~/.xinitrc}} has {{ic|--exit-with-session}} set in the {{ic|dbus_args}}. <br />
<br />
Try copying {{ic|~/.xinitrc}} to {{ic|~/.xrdpinitrc}}, removing {{ic|--exit-with-session}}, and updating {{ic|/etc/xrdp/startwm.sh}} to call {{ic|~/.xrdpinitrc}} instead of {{ic|~/.xinitrc}}. You might need to append your desktop environment to the call to .xrdpinitrc, as is mentioned in ~/.xinitrc; eg. {{ic|. ~/.xrdpinitrc xfce}}.<br />
<br />
<br />
* If you are prompted to login to gnome-keyring when your session starts add the following 2 lines to {{ic|/etc/pam.d/xrdp-sesman}}<br />
{{bc|<nowiki><br />
auth optional pam_gnome_keyring.so<br />
session optional pam_gnome_keyring.so auto_start<br />
</nowiki>}}<br />
<br />
<br />
* To prevent user defined {{ic|~/.config/autostart}} items for a from starting you can set the autostart directory param on the session in the {{ic|~/.xinitrc}} to use only the global {{ic|/etc/xdg/autostart}} directory. <br />
<br />
{{bc|<nowiki><br />
get_session(){<br />
local dbus_args=(--sh-syntax)<br />
case "$SESSION" in<br />
awesome) dbus_args+=(awesome) ;;<br />
bspwm) dbus_args+=(bspwm-session) ;;<br />
budgie) dbus_args+=(budgie-desktop) ;;<br />
cinnamon) dbus_args+=(cinnamon-session -a /etc/xdg/autostart) ;;<br />
</nowiki>}}<br />
<br />
=== Running with Vino (Gnome VNC-Server for root session) ===<br />
<br />
Enable the server to be seen via vino-preferences. Since vino defaults to port 5900 for connections, we will edit the xrdp configuration file to understand this. Append the vino session to xrdp's configuration file:<br />
<br />
{{hc|/etc/xrdp/xrdp.ini|2=<br />
[xrdp8]<br />
name=Vino-Session<br />
lib=libvnc.so<br />
username=ask<br />
password=ask<br />
ip=127.0.0.1<br />
port=5900<br />
}}<br />
<br />
If you encounter VNC connection errors, it may be because {{ic|vino-server}} defaults to accepting only TLS connections. This must be changed to standard VNC authentication so that {{ic|xrdp}} may connect:<br />
gsettings set org.gnome.Vino require-encryption false<br />
<br />
You can also restrict {{ic|vino-server}} to only listen on the loopback interface:<br />
gsettings set org.gnome.Vino network-interface lo<br />
<br />
Remember to restart the xrdp server, and one should be able to connect to the vino session (tested using xfreerdp).<br />
<br />
== Usage ==<br />
After starting the {{ic|xrdp}} and {{ic|xrdp-sesman}} services, you should be able to connect an RDP client to the host on the default RDP port (3389). If successful, you will be greeted with the ''xrdp'' session manager window which allows you to choose between ''Xorg'' or ''Xvnc'' sessions and provides inputs for user authentication. The session manager UI can be highly customized by modifying {{ic|/etc/xrdp/xrdp.ini}}.<br />
<br />
The parameters used to start ''Xorg'' and ''Xvnc'' display servers can be configured in {{ic|/etc/xrdp/sesman.ini}}.<br />
<br />
After successfully starting a display server, ''xrdp'' will execute {{ic|/etc/xrdp/startwm.sh}} by default. This script is meant to start a window manager (similar to [[.xinitrc]]) and will typically require modification to start your desired window manager. Note: the default script will attempt to start {{ic|xterm}} which will cause the connection to fail if {{ic|xterm}} is not installed.<br />
<br />
If you just close the session window and RDP connection, you can access the same session again next time you connect with RDP. When you exit the window manager or desktop environment from the session window, the session will close and a new session will be opened the next time.<br />
<br />
''xrdp'' checks only if a session with the same geometry is already opened.<br />
It will start a new session if the geometry/resolution doesn't match.<br />
<br />
== See also ==<br />
<br />
* [[TigerVNC]] - VNC, an alternative to RDP, also used as backend here<br />
*{{Pkg|freerdp}} a rdesktop fork that supports RDP 7.1 features including network level authentication (NLA). See also [https://askubuntu.com/a/97932].</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices&diff=651118Chrome OS devices2021-02-06T21:20:31Z<p>Phil.r.dubois: /* General hardware recommendations and remarks */ SDD to SSD</p>
<hr />
<div>[[Category:Chrome OS devices]]<br />
[[ja:Chrome OS デバイス]]<br />
{{Related articles start}}<br />
{{Related|Chrome OS devices/Crostini}}<br />
{{Related|Chrome OS devices/Chromebook}}<br />
{{Related|Chrome OS devices/Custom firmware}}<br />
{{Related|Installation guide}}<br />
{{Related|Laptop}}<br />
{{Related articles end}}<br />
{{Warning|This article relies on third-party scripts and modifications, and may irreparably damage your hardware or data. Proceed at your own risk.}}<br />
This article was created to provide information on how to get Arch installed on the series of Chrome OS devices built by Acer, HP, Samsung, Toshiba, and Google. Currently this page is being overhauled, and more model specific pages are being built with some of the information listed below. <br />
<br />
{{Note|This article describes how to install Arch Linux by activating developer mode. For instructions on how to install Arch Linux in a ChromeOS container without having to enable developer mode see [[Crostini]]}}<br />
<br />
== Introduction ==<br />
<br />
=== Legacy Boot Mode ===<br />
<br />
All recent Intel-based Chrome OS devices (starting with the 2013 Chromebook Pixel) feature a Legacy Boot Mode, designed to allow the user to boot Linux. Legacy Boot Mode has a dedicated firmware region, {{ic|RW_LEGACY}}, which is designed to be user-writeable (hence the 'RW' notation) and is completely separate from the ChromeOS portion of the firmware (ie, it is safe to update and cannot brick the device). It is enabled by the [http://www.coreboot.org/SeaBIOS SeaBIOS] payload of [http://www.coreboot.org/ coreboot], the open-source firmware used for all Chrome OS devices (with the exception of the first generation of Chromebooks and a few early ARM models). SeaBIOS behaves like a traditional BIOS that boots into the MBR of the disk, and from there into standard bootloaders like Syslinux and GRUB.<br />
<br />
Models with a Core-i based SoC (Haswell, Broadwell, Skylake, KabyLake) mostly ship with a functional Legacy Boot Mode payload; updating to a 3rd party build can provide bug fixes and additional features. Models with an Atom-based SoC (Baytrail, Braswell, Apollolake) have Legacy Boot Mode capability, but do not ship with a RW_LEGACY/SeaBIOS payload (that part of the firmware is blank). These models require a 3rd party RW_LEGACY firmware to be loaded for Legacy Boot Mode to be functional.<br />
<br />
<br />
==== Models without Legacy Boot Mode/SeaBIOS ====<br />
<br />
One of the following approaches can be taken in order to install Arch Linux on Chrome OS devices which did not ship with SeaBIOS as part of the installed firmware:<br />
<br />
* If the device supports Legacy Boot Mode, but does not ship with a functional {{ic|RW_LEGACY}} payload (or doesn't ship with one at all), one can flash a SeaBIOS payload to the {{ic|RW_LEGACY}} part of the firmware. This is 100% safe, as it writes to a user-writeable area of the firmware image which is completely separate from/does not affect ChromeOS. The easiest way to install/update the RW_LEGACY firmware on your ChromeOS device is via MrChromebox's [[Chrome_OS_devices/Custom_firmware#Flashing_with_MrChromebox.27s_Firmware_Utility_Script|Firmware Utility Script]], which supports the widest range of devices and offers the most up-to-date SeaBIOS builds; one can also update the {{ic|RW_LEGACY}} firmware manually with Chrome OS' {{ic|flashrom}} (requires downloading/compiling your own build), or use John Lewis' {{ic|flash_chromebook_rom.sh}} script (no longer supported).<br />
<br />
* Flash a full [[Custom firmware for Chrome OS devices|custom firmware]] which includes either a SeaBIOS or UEFI payload, and removes all the ChromeOS-specific parts.<br />
<br />
* Flash the {{ic|BOOT_STUB}} part of the firmware. This method replaces the stock ChromeOS payload (depthcharge) with SeaBIOS. This is theoretically a safer approach than flashing the full firmware but there might be some limitations (e.g. no support in suspend or VMX). This is the {{ic|Modify ROM to run SeaBIOS exclusively}} option in John Lewis' {{ic|flash_chromebook_rom.sh}} script and {{ic|Flash BOOT_STUB firmware}} option in MrChromebox's.<br />
<br />
* Take the ChrUbuntu approach which uses the Chrome OS kernel and modules.<br />
<br />
* Build and sign your own kernel, see [https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP] [https://pomozok.wordpress.com/2014/10/11/building-chromeos-kernel-without-chroot/] [https://github.com/drsn0w/chromebook_kernel_tools/blob/master/install_linux.md]{{Dead link|2020|03|28|status=404}}.<br />
<br />
The [[#Installation|Installation]] process described on this page tries to cover the method of installing Arch Linux on models without SeaBIOS by flashing a custom firmware.<br />
<br />
=== Firmware write protection intro ===<br />
<br />
All Chrome OS devices features firmware write protection, which restricts write access to certain regions of the flash chip. It is important to be aware of it as one might need to disable the hardware write protection as part of the installation process (to update GBB flags or flash a custom firmware).<br />
<br />
For more details see [[Custom firmware for Chrome OS devices#Firmware write protection|Firmware write protection]].<br />
<br />
=== Prerequisites ===<br />
<br />
* You should claim your free 100GB-1TB of Google Drive space before you install Arch. This needs to happen from ChromeOS(version > 23), not linux. This will sync/backup ChromeOS, as designed<br />
* Visit the ArchWiki page for your [[#Chrome OS devices|Chrome OS device]].<br />
* If there is no ArchWiki page for your device then before proceeding, gather information about the device and if you succeed in installing Arch Linux, then consider adding a new ArchWiki page for your model (you can use the [[Acer C720]] as an example for device shipped with SeaBios or the [[Acer_C710_Chromebook|Acer C710]] as device that did not ship with it).<br />
* Read this guide completely and make sure you understand all the steps before making any changes.<br />
<br />
== Chrome OS devices ==<br />
<br />
See [[Chrome_OS_devices/Chromebook|Chromebook models]] for hardware comparison with details about SeaBIOS availability and storage expansion.<br />
<br />
=== General hardware recommendations and remarks ===<br />
<br />
* MyDigitalSSD M.2 NGFF SSD drives are probably the most popular choice when upgrading the internal SSD of a Chrome OS device. There are multiple accounts of failing MyDigitalSSD SSD drives at the Acer C720 topic on the Arch forums [https://bbs.archlinux.org/viewtopic.php?pid=1461993#p1461993] [https://bbs.archlinux.org/viewtopic.php?pid=1474680#p1474680] [https://bbs.archlinux.org/viewtopic.php?pid=1460460#p1460460] and much more on the web. If the SSD was upgraded to a MyDigitalSSD model then it is highly recommended to backup the system and data frequently. It might be advisable to upgrade the SSD with a different brand. Notice that this might be due to a SSD firmware issue so updating the SSD firmware is highly recommended.<br />
* Transcend MTS400 M.2 NGFF SSD drives are failing (at least with stock Coreboot firmware) when ALPM is enabled, ATM there is no SSD firmware update that fixing this bug, so it is highly advisable to disabled ALPM if a power management daemon has been installed (which enabled it), see [[Solid_State_Drives#Resolving_SATA_power_management_related_errors|Resolving SATA power management related errors]] and [https://superuser.com/questions/887916/transcend-mts400-ssd-crashes-my-acer-c720-chromebook-how-to-disable-sata-power how to disable ALPM in Chrome OS].<br />
<br />
== Installation ==<br />
<br />
{{Warning|Installation on ChromeOS devices that do not ship with SeaBIOS requires flashing a custom firmware, certain types of which have the potential to brick your device. Proceed at your own risk.}}<br />
<br />
{{Note|While the following information should fit all the ChromeOS devices with coreboot firmware (shipped with SeaBIOS payload or without), it is possible that with some models you may need to make further adjustments.}}<br />
<br />
The general installation procedure:<br />
* Enable developer mode.<br />
* ChromeOS device with functional Legacy Boot Mode/SeaBIOS:<br />
** Enable Legacy Boot Mode.<br />
** Set SeaBIOS as default (optional but highly recommended, requires disabling the write protection).<br />
* ChromeOS device without functional Legacy Boot Mode:<br />
** Flash one of the following types of custom firmware<br />
*** Flash RW_LEGACY firmware (zero risk)<br />
*** Flash BOOT_STUB firmware (very low risk).<br />
*** Flash Full custom firmware (low risk).<br />
* Prepare the installation media.<br />
* Boot Arch Linux installation media and install Arch.<br />
<br />
=== Enabling developer mode ===<br />
<br />
[http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Developer-Mode Developer Mode] is necessary in order to access the superuser shell inside ChromeOS, which is required for making changes to the system like allow booting through SeaBIOS.<br />
<br />
{{Warning|Enabling Developer Mode will wipe all of your data.}}<br />
<br />
To enable developer mode: <br />
<br />
* Press and hold the {{ic|Esc + F3 (Refresh)}} keys, then press the {{ic|Power}} button. This enters Recovery Mode.<br />
** Chromeboxes have a dedicated Recovery button, which should be pressed/held while powering on<br />
* Press {{ic|Ctrl + D}} (no prompt). It will ask you to confirm, then the system will revert its state and enable Developer Mode.<br />
{{Note|Press {{ic|Ctrl + D}} (or wait 30 seconds for the beep and boot) at the white boot splash screen to enter ChromeOS.}}<br />
<br />
=== Accessing the superuser shell ===<br />
<br />
After you have enabled the Developer Mode you will need to access the superuser shell. How you do this depends on whether you have configured ChromeOS or not.<br />
<br />
==== Accessing the superuser shell without logging into ChromeOS ====<br />
<br />
If you have not configured ChromeOS, just press {{ic|Ctrl + Alt + F2}} (F2 is the "forward" arrow on the top row, →), you will see a login prompt.<br />
<br />
* Use {{ic|chronos}} as the username, it should not prompt you for a password.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}}.<br />
<br />
==== Accessing the superuser shell when logged into ChromeOS ====<br />
<br />
If you have configured ChromeOS already:<br />
<br />
* Open a crosh window with {{ic|Ctrl + Alt + T}}.<br />
* Open a bash shell with the {{ic|shell}} command.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}} to accomplish that.<br />
<br />
=== Enabling Legacy Boot Mode ===<br />
<br />
If your ChromeOS device did not ship with Legacy Boot Mode support via SeaBIOS, or you prefer to install a custom firmware, then continue to [[#Flashing a custom firmware|Flashing a custom firmware]].<br />
<br />
This will enable the pre-installed version of SeaBIOS through the Developer Mode screen in coreboot.<br />
<br />
* Inside your superuser shell enter:<br />
# crossystem dev_boot_legacy=1<br />
* Reboot the machine.<br />
<br />
You can now start SeaBIOS by pressing {{ic|Ctrl + L}} at the white boot splash screen.<br />
<br />
{{Note|If you intend to stay using pre-installed SeaBIOS route and think you will not appreciate having to press {{ic|Ctrl + L}} every time you boot to reach SeaBIOS, then you can set coreboot to boot to SeaBIOS by default. This requires disabling the hardware firmware write protection.}}<br />
<br />
You should now have SeaBIOS enabled on your ChromeOS device, if you choose to not set it as default then you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
==== Boot to SeaBIOS by default ====<br />
<br />
To boot SeaBIOS by default, you will need to run the [https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/master/scripts/image_signing/set_gbb_flags.sh {{ic|set_gbb_flags.sh}}] script, which is part of ChromeOS. The script uses flashrom and gbb_utility to read the RO_GBB firmware region, modify the flags, and write it back to flash. The GBB flags can also be set using MrChromebox's [https://mrchromebox.tech/#fwscript Firmware Utility Script] under either ChromeOS or Arch (the latter requiring booting with specific kernel parameters to relax memory access restrictions).<br />
<br />
{{Warning|If you do not set the GBB flags, then a fully discharged or disconnected battery will reset {{ic|dev_boot_legacy}} crossystem flag to its default value, removing the ability to boot in Legacy Boot Mode. While this used to require you to recover Chrome OS and wipe your Arch Linux installation on the internal storage, the GalliumOS developers have created a set of "fixflags" recovery images, which rather than wiping internal storage, will instead simply re-set the {{ic|dev_boot_legacy}} crossystem flag. See [https://galliumos.org/fixflags galliumos.org/fixflags]}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page]{{Dead link|2020|03|28|status=404}}.<br />
<br />
More information about the firmware protection available in [[Chrome OS devices/Custom firmware#Firmware write protection]].<br />
<br />
* Switch to the [[#Accessing the superuser shell|superuser shell]].<br />
<br />
* Disable the software write protection.<br />
# flashrom --wp-disable<br />
<br />
* Check that write protection is disabled.<br />
# flashrom --wp-status<br />
<br />
* Run {{ic|set_gbb_flags.sh}} with no parameters.<br />
# /usr/share/vboot/bin/set_gbb_flags.sh<br />
<br />
* This will list all of the available flags. The ones of interest to us are:<br />
GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001<br />
GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008<br />
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080<br />
GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY 0x00000400<br />
<br />
* So, to set SeaBIOS as default, with a 1s timeout, prevent accidentally exiting Developer Mode via spacebar, and ensure Legacy Boot Mode remains enabled in the event of battery drain/disconnect, we set the flags as such:<br />
# /usr/share/vboot/bin/set_gbb_flags.sh 0x489<br />
<br />
* Enable back the software write protection.<br />
# flashrom --wp-enable<br />
<br />
{{Note|All of these steps are automated by MrChromebox's Firmware Utility Script, so if using that to install/update your RW_LEGACY firmware, easiest to just set the flags via the script as well.}}<br />
<br />
Your ChromeOS device now will boot to SeaBIOS by default, you can continue to [[#Installing Arch Linux|Installing Arch Linux]], if your device is booting correctly then you can optionally re-enable the hardware write protection.<br />
<br />
=== Flashing a custom firmware ===<br />
<br />
{{Note|The following steps explain how to flash a custom firmware from ChromeOS, for information on how to flash a custom firmware from Arch Linux visit the [[Chrome OS devices/Custom firmware]] page}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devicesDeveloper Information for ChromeOS Devices]{{Dead link|2020|03|28|status=404}} and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page]{{Dead link|2020|03|28|status=404}}.<br />
<br />
More information about the firmware protection available in [[Chrome OS devices/Custom firmware#Firmware write protection]].<br />
<br />
* Enter the command to run either MrChromebox's or John Lewis's firmware script.<br />
<br />
{{Note|The reason for not posting here is to force you to visit the site and read the instructions before proceeding.}}<br />
<br />
* After the exiting the script, be sure to copy the backed up firmware to an external storage before rebooting the system (if the script doesn't provide that option for you).<br />
<br />
You should now have a custom firmware installed on your device, cross your fingers and reboot.<br />
<br />
After flashing the firmware you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
=== Installing Arch Linux ===<br />
<br />
==== Preparing the installation media ====<br />
<br />
Create an [[USB flash installation media|Arch Linux Installer USB drive]].<br />
<br />
{{Note|If the USB loads but fails to boot into Arch, it may be due a bug in the syslinux the current (2017.03.01) installer uses. The 2016.11.01 version from the [[Arch Linux Archive]] will work until the issue is resolved.}}<br />
<br />
==== Booting the installation media ====<br />
<br />
* Plug the USB drive to the ChromeOS device and start SeaBIOS with {{ic|Ctrl + L}} at the white boot splash screen (if SeaBIOS is not set as default).<br />
* Press {{ic|Esc}} to get a boot menu and select the number corresponding to your USB drive.<br />
<br />
The Arch Linux installer boot menu should appear and the [[Installation guide|installation]] process can proceed as normal.<br />
<br />
{{Note|For now choose [[GRUB]] as your bootloader: you can choose MBR or GPT: [[Partitioning]]. If you choose GPT then do not forget to add a [[GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions|BIOS Boot Partition]]. Also see [[#Syslinux|Known Issues]].}}<br />
<br />
After finishing installing Arch Linux continue by following the [[#Post installation configuration|Post Installation Configuration]].<br />
<br />
== Post installation configuration ==<br />
<br />
=== Patched kernels ===<br />
{{Note|You can most likely ignore this section unless your device requires patched kernel support.}}<br />
<br />
It is recommended to use the official {{Pkg|linux}} package for most Chrome OS devices with the exception being newer devices which might need patched kernel support such as the Chromebook Pixel 2015.<br />
<br />
{{AUR|linux-samus4}} provides patches for the Chromebook Pixel 2015 to fix touchpad, touchscreen, and sound functionality which has not been merged into upstream linux yet. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
If your devices requires a patched kernel, it is advised to review the list of patches and decide if the patch list is getting decidedly small enough that you no longer require a patched kernel and instead you can use the official {{Pkg|linux}} package instead. <br />
<br />
See [[kernels]] for more information.<br />
<br />
=== Video driver ===<br />
<br />
See [[Intel graphics]].<br />
<br />
=== Touchpad and touchscreen ===<br />
<br />
See [[Touchpad Synaptics]], [[libinput]], and [[Touchscreen]].<br />
<br />
==== Touchpad and touchscreen kernel modules ====<br />
<br />
Since kernel 3.17 all the related patches merged into the upstream sources, meaning the {{Pkg|linux}} package in core supports these devices.<br />
<br />
===== What to do if your touchpad or touchscreen is not supported? =====<br />
<br />
* Do not worry as the developers should be able to add it by request as the Chromium OS sources includes the related changes.<br />
* You can also try to find the related commits by yourself and create a proper patch, some hints:<br />
** Dig into your Chrome OS system, look at the obvious suspects like boot log, {{ic|/proc/bus/input/devices}} and {{ic|/sys/devices}}.<br />
** The Linux kernel sources for Chromium OS are at [https://chromium.googlesource.com/chromiumos/third_party/kernel].<br />
** Each kernel source for the latest Chromium OS release has its own branch, name convention: {{ic|release-R*-*-chromeos-KERNELVER}}, where {{ic|R*-*}} is the Chromium OS release and {{ic|KERNELVER}} is the kernel version.<br />
** Review the git log of {{ic|drivers/platform}}, {{ic|drivers/i2c/busses}} and {{ic|drivers/input/touchscreen}}.<br />
* {{AUR|linux-samus4}} includes touchpad and touchscreen support for the Chromebook Pixel 2015. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
==== Touchpad configuration ====<br />
<br />
There are few options how to set the touchpad:<br />
<br />
* Visit the ArchWiki page for your Chromebook model (see [[Chrome_OS_devices/Chromebook|Chromebook models]]) for touchpad xorg.conf.d file.<br />
* Use a [[Touchpad_Synaptics#Configuration_on_the_fly|touchpad configuration tool]].<br />
<br />
==== Chromium OS input drivers ====<br />
<br />
{{Out of date|{{ic|xf86-input-cmt}} development is not active and it is probably not needed anymore in any case since [[libinput]]'s compatibility with Chrome OS devices's touchpads is fairly good.}}<br />
<br />
{{AUR|xf86-input-cmt}} offers a port of the Chromium OS input driver: [https://github.com/hugegreenbug/xf86-input-cmt xf86-input-cmt] as an alternative for the [[Synaptics|Synaptics input driver]]. It provides tweaked configuration files for most devices, and provides functionality that the [[Synaptics|Synaptics input driver]] does not such as palm rejection. Additionally, it enables functionality not enabled by default in the Chromium OS input driver such as tap-to-drag.<br />
<br />
Please note, the input driver does not work under [https://github.com/hugegreenbug/xf86-input-cmt/issues/5 some circumstances] where you have insufficient permissions to access {{ic|/dev/input/event}}<br />
This will affect you if you use [[startx]] to load a DE/WM session.<br />
If this is the case or if the driver does not load for any other cases, you should run:<br />
# usermod -a -G input $USER<br />
Where $USER is the current user wanting to use the input driver.<br />
<br />
It should also be noted that some users have reported the driver does not work in [[GDM]] but works normally after log in.<br />
If you are affected by this, you should run:<br />
# usermod -a -G input gdm<br />
<br />
After reboot, you should be able to use the touchpad normally.<br />
<br />
=== Fixing suspend ===<br />
{{Note|Lid suspend might not work directly after boot, you might need to wait a little.}}<br />
<br />
The following are instructions to fix the suspend functionality.<br />
Users of a pre-installed SeaBIOS or John Lewis' pre-built SeaBIOS you will need this fix.<br />
This procedure is not needed with Matt DeVillier's custom firmware since problematic ACPI wake devices (such as {{ic|TPAD}}) are firmware-disabled.<br />
<br />
There have been a few alternatives discussed and those may work better for some. [https://bbs.archlinux.org/viewtopic.php?pid=1364376#p1364376] [https://bbs.archlinux.org/viewtopic.php?pid=1364521#p1364521]<br />
<br />
To fix suspend, the general idea is to disable the EHCI_PCI module, which interferes with the suspend cycle. There are multiple ways to achieve this.<br />
<br />
==== With kernel parameters ====<br />
Add the following to your GRUB configuration:-<br />
<br />
{{hc|head=/etc/default/grub|<br />
output=GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=ehci_pci"}}<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]]. After rebuilding your GRUB config, reboot your computer.<br />
<br />
==== With systemd ====<br />
<br />
Sometimes the synaptics touchpad, and various other parts of the laptop are used as wakeup devices causing certain movements of the laptop during suspend to end suspend. In order to disable all wakeup devices except for the laptop lid sensor, create the following {{ic|suspend-device-fix.sh}} file. <br />
<br />
{{hc|head=/usr/local/sbin/suspend-device-fix.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
awk '{if ($1 != "LID0" && $3 == "*enabled") print $1}' < /proc/acpi/wakeup | while read NAME<br />
do echo "$NAME" > /proc/acpi/wakeup<br />
done<br />
<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now give the file executable permissions:<br />
# chmod +x /usr/local/sbin/suspend-device-fix.sh<br />
<br />
Create a systemd service to execute the script on every boot. <br />
{{hc|head=/etc/systemd/system/suspend-fix.service|<br />
output=[Unit]<br />
Description=Suspend Fix<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/local/sbin/suspend-device-fix.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
First [[start]] {{ic|suspend-fix.service}}. If it properly starts, then [[enable]] it to be started on bootup.<br />
<br />
Add the following line at the end of {{ic|/etc/rc.d/rc.local}} (if it does not exist, just create it) to prevent bad handling of EHCI USB:<br />
<br />
{{hc|head=/etc/rc.d/rc.local|<br />
output=<nowiki><br />
echo 1 > /sys/devices/pci0000\:00/0000\:00\:1d.0/remove<br />
</nowiki>}}<br />
<br />
Then, create the following {{ic|cros-sound-suspend.sh}} file. Only the Ath9k binding/unbinding lines are listed below; see the alternatives linked above for additional sound suspend handling if you experience issues.<br />
<br />
{{hc|head=/usr/lib/systemd/system-sleep/cros-sound-suspend.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
case $1/$2 in<br />
pre/*)<br />
# Unbind ath9k for preventing error and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/unbind<br />
# Unbind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
;;<br />
post/*)<br />
# Bind ath9k for preventing error and and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/bind<br />
# bind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
;;<br />
esac</nowiki>}}<br />
<br />
Make sure to make the script executable:<br />
# chmod +x /usr/lib/systemd/system-sleep/cros-sound-suspend.sh<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]].<br />
<br />
=== Fixing audio ===<br />
<br />
==== Baytrail based models ====<br />
<br />
Audio on most baytrail models should work on {{Pkg|linux}} since fix merged into 4.19.7 [https://git.archlinux.org/linux.git/commit/?h=v4.19.7-arch1&id=f35f68c68ce48a8b70a4c3674663513825b7a1bc], to fix regression in 4.18.15, see bug report [https://lkml.org/lkml/2018/10/30/676].<br />
<br />
It is likely that you will also need to use {{ic|alsamixer}} from {{Pkg|alsa-utils}} to turn on "Left Speaker Mixer Left DAC" and "Right Speaker Mixer Right DAC". For more information, see {{Bug|48936}}.<br />
<br />
==== Haswell based models ====<br />
<br />
One or more of followings might help solving audio related issues, setting {{ic|snd_hda_intel}} module index reported the most useful. It is highly possible that you will not need to make any change.<br />
<br />
* Create {{ic|/etc/modprobe.d/alsa.conf}}, the option {{ic|index}} will make sure the analog output is the default (and not HDMI), the option {{ic|model}} will notify the driver our board model which will make the built-in microphone usable (you can try instead {{ic|<nowiki>model=alc283-sense-combo</nowiki>}} or {{ic|<nowiki>model=,alc283-dac-wcaps</nowiki>}}). <br />
<br />
{{hc|head=/etc/modprobe.d/alsa.conf|<br />
output=options snd_hda_intel index=1 model=,alc283-chrome}}<br />
<br />
* Use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/52d6d7d97eff76935713/raw/5b32ee11a2ebbe7a3ee0f928e49b980361a57548/.asoundrc].<br />
<br />
* If having problems with headphones (perhaps no audio playing), try {{ic|alsactl restore}} (requires {{Pkg|alsa-utils}}) in terminal. Now, ALSA should automatically switch between channels when using headphones/speakers. <br />
<br />
* To fix [[Flash]] audio with PulseAudio, use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/0eebff16cd9578c5e035/raw/d4c974fcd50565bf116c57b1884170ecb47f8bf6/.asoundrc].<br />
<br />
==== Chromebook Pixel 2015 ====<br />
<br />
{{AUR|linux-samus4}} includes a patch for Broadwell SoC sound devices. [https://github.com/raphael/linux-samus Its GitHub page] includes additional instructions for initializing the sound device.<br />
<br />
=== Hotkeys ===<br />
<br />
[https://support.google.com/chromebook/answer/1047364?hl=en The Chromebook function keys] recognized as standard F1-F10 by the kernel, it is preferable to map them accordingly to their appearance. It would also be nice to get the keys {{ic|Delete, Home, End, PgUp, PgDown}} which in Chrome OS mapped to {{ic|Alt + : BackSpace, Right, Left, Up, Down}}.<br />
<br />
==== xkeyboard configuration ====<br />
<br />
{{Pkg|xkeyboard-config}} 2.16-1 added a {{ic|chromebook}} model that enables the Chrome OS style functions for the function keys. You can, for example, set this using {{ic|localectl set-x11-keymap us chromebook}}. See the {{ic|chromebook}} definition in {{ic|/usr/share/X11/xkb/symbols/inet}} for the full mappings.<br />
<br />
==== Sxhkd configuration ====<br />
<br />
One way to set the hotkeys would be by using the [[Sxhkd]] daemon. Besides {{Pkg|sxhkd}}, this also requires [[Advanced Linux Sound Architecture|amixer]], {{Pkg|xorg-xbacklight}}, and {{Pkg|xautomation}}.<br />
<br />
* See [https://gist.github.com/dhead666/191722ec04842d8d330b] for an example configuration in {{ic|~/.config/sxhkd/sxhkdrc}}.<br />
<br />
==== Xbindkeys configuration ====<br />
<br />
Another way to configure hotkeys would be by using [[Xbindkeys]]. Besides {{Pkg|xbindkeys}} this requires [[Advanced Linux Sound Architecture|amixer]] and {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* See [https://gist.github.com/dhead666/08562a9a760b18b6e758] for an example configuration in {{ic|~/.xbindkeysrc}}.<br />
* See [https://bbs.archlinux.org/viewtopic.php?id=173418&p=3 vilefridge's xbindkeys configuration] for another example.<br />
<br />
===== Alternate xbindkeys configuration =====<br />
<br />
[http://pastie.org/9550960 Volchange]{{Dead link|2020|05|25|status=410}} (originated in the [http://www.debianuserforums.org/viewtopic.php?f=55&t=1453#p14351 Debian User Forums]{{Dead link|2020|05|25|status=domain name not resolved}})) can manipulate the volume with PulseAudio instead of using [[Advanced Linux Sound Architecture|amixer]]. Besides [http://pastie.org/9550960 Volchange]{{Dead link|2020|05|25|status=410}} this requires {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* Download the script from [http://pastie.org/9550960]{{Dead link|2020|05|25|status=410}}.<br />
* Make it executable <br />
$ chmod u+x ~/.local/bin/volchange<br />
<br />
See [https://gist.github.com/dhead666/4e23b506441ad424e26e] for a matching {{ic|~/.xbindkeysrc}}.<br />
<br />
==== Patch xkeyboard-config ====<br />
<br />
Another option is to install {{AUR|xkeyboard-config-chromebook}}, for more details visit [https://github.com/dhead666/archlinux-pkgbuilds/tree/master/xkeyboard-config-chromebook].<br />
<br />
==== Mapping in Gnome with gsettings set ====<br />
<br />
Some of the function keys can be mapped in Gnome with the advantage of HUD notifications on changes (like volume and brightness changes) which can supplement one of the mapping methods mentioned above. This [https://gist.github.com/dhead666/0b9c1cc9def939705594 linked example] maps the brightness and volume actions. Notice that {{Pkg|xdotool}} is required.<br />
<br />
=== Power key and lid switch handling ===<br />
<br />
==== Ignore using logind ====<br />
<br />
Out of the box, {{ic|systemd-logind}} will catch power key and lid switch events and handle them: it will shut down the Chromebook on a power key press, and a suspend on a lid close. However, this policy might be a bit harsh given that the power key is an ordinary key at the top right of the keyboard that might be pressed accidentally.<br />
<br />
To configure logind to ignore power key presses and lid switches, add the lines to {{ic|logind.conf}} below.<br />
<br />
{{hc|head=/etc/systemd/logind.conf|<br />
output=HandlePowerKey=ignore<br />
HandleLidSwitch=ignore}}<br />
<br />
Then [[restart]] logind for the changes to take effect.<br />
<br />
Power key and lid switch events will still be logged to journald by logind. See [[Power management#ACPI events]].<br />
<br />
==== Ignore by Gnome ====<br />
<br />
[[Install]] {{Pkg|gnome-tweaks}}, open the Tweak Tool and under Power change the Power Button Action.<br />
<br />
== Known issues ==<br />
<br />
=== Syslinux ===<br />
<br />
Follow Syslinux installation instructions carefully. Try manual installation to see where the problem comes from. If you see [[Syslinux#Missing_operating_system|Missing Operation System]] then it may be because you need to use correct bootloader binary. If syslinux does not work try another [[bootloader]] such as [[GRUB]].<br />
<br />
== See also ==<br />
<br />
* [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for Chrome OS Devices at the Chromium Projects site]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=173418 BBS topic about the Acer C720] which include generic information on Haswell Based Chromebooks.<br />
* Re-partitioning in Chrome OS [http://chromeos-cr48.blogspot.co.uk/2012/04/chrubuntu-1204-now-with-double-bits.html], [http://goo.gl/i817v]{{Dead link|2020|03|28|status=404}}<br />
* [http://bit.ly/NewChromebooks Brent Sullivan's the always updated list of Chrome OS devices]<br />
* [http://prodct.info/chromebooks/ Google Chromebook Comparison Chart]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Security&diff=626822Security2020-07-25T22:07:02Z<p>Phil.r.dubois: /* Boot partition on removable flash drive */ fixed wording of previous edit</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<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|Security package guidelines}}<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]], [[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 phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<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 (8-64 characters, longer is better) and generated from a random source.<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 />
There are also techniques for building memorable secure passwords.<br />
<br />
One technique is to use a mnemonic phase, where each word in the phase 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 technique is to use a memorable long series of unrelated words as a password. 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. The [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method uses a long passphrase in combination with a random number generator (game dice).<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. [https://www.schneier.com/news/archives/2010/11/bruce_schneier_write.html Bruce Schneier has endorsed this technique].<br />
<br />
It is also very effective to combine the memorable 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 />
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), 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}}).<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}} 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 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 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 />
<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 (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 />
<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 />
== CPU ==<br />
<br />
=== Microcode ===<br />
<br />
See [[microcode]] for information on how to install important security updates for your CPU's microcode.<br />
<br />
=== Disable hyper-threading ===<br />
<br />
If your computer contains an [[Intel]] CPU, disabling [[Wikipedia: Hyper-threading|hyper-threading]] is a security consideration due to [[Wikipedia:Microarchitectural Data Sampling|Microarchitectural Data Sampling]], see https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html. [https://www.youtube.com/watch?v=jI3YE3Jlgw8 Kernel developer Greg Kroah-Hartman has endorsed disabling hyper-threading] as a security hardening option for systems running untrusted code, such as web browsers that enable Javascript.<br />
<br />
To check if you are affected, run the following:<br />
<br />
$ grep . -r /sys/devices/system/cpu/vulnerabilities/<br />
<br />
If the output contains {{ic|SMT vulnerable}}, you should disable hyper-threading. Note that there will be a performance impact and you should consider if the trade-off is acceptable.<br />
<br />
Hyper-threading can often be disabled in your system's firmware. Consult your motherboard or system documentation for more information. You can also disable hyper-threading in the kernel by adding the following [[kernel parameters]]:<br />
<br />
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force<br />
<br />
Reboot afterwards and verify the output of grep. It should now say {{ic|SMT disabled}}.<br />
<br />
=== CPU vulnerabilities ===<br />
<br />
{{Expansion|Give a good set of defaults, plus discussion of the tradeoffs involved.}}<br />
<br />
In the wake of the Spectre/Meltdown vulnerabilities, certain configurable mitigations have been added to the kernel. Refer to the [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation] for more details.<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 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}}. For example, {{ic|man}} fails to work properly unless its {{ic|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 />
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 />
=== 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 />
== 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|2=<br />
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=<br />
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. Alternatively, use [[Wayland]] instead of Xorg.<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 is 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|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|<br />
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 />
How ever, 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 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/51-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
{{Tip|This is enabled by default in {{pkg|linux-hardened}}.}}<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://www.kernel.org/doc/html/latest/admin-guide/sysctl/net.html kernel documentation] for more details.<br />
<br />
{{Tip|{{pkg|linux-hardened}} sets {{ic|1=net.core.bpf_jit_harden=2}} by default rather than {{ic|0}}.}}<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama [[Wikipedia:Linux Security Modules|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}} [[Capabilities|capability]]. 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 />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<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 />
=== 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 in https://www.kernel.org/doc/html/latest/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://www.kernel.org/doc/html/latest/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, check it by running {{ic|cat /sys/kernel/security/lsm}}. If the output does not have {{ic|lockdown}} in it, set the [[kernel parameter]] {{ic|1=lsm=lockdown,yama}} and reboot.<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 />
== 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) 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 />
<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 />
=== 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 is 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 {{ic|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 />
== 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/]{{Dead link|2020|04|03|status=SSL error}} 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 />
[[#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 />
=== 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://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 />
== 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. 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 />
== 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-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>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Security&diff=626821Security2020-07-25T22:05:43Z<p>Phil.r.dubois: /* Boot partition on removable flash drive */ mentioned the method can be merged with locking down the boot loader</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<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|Security package guidelines}}<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]], [[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 phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<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 (8-64 characters, longer is better) and generated from a random source.<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 />
There are also techniques for building memorable secure passwords.<br />
<br />
One technique is to use a mnemonic phase, where each word in the phase 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 technique is to use a memorable long series of unrelated words as a password. 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. The [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method uses a long passphrase in combination with a random number generator (game dice).<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. [https://www.schneier.com/news/archives/2010/11/bruce_schneier_write.html Bruce Schneier has endorsed this technique].<br />
<br />
It is also very effective to combine the memorable 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 />
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), 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}}).<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}} 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 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 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 />
<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 (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 />
<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 />
== CPU ==<br />
<br />
=== Microcode ===<br />
<br />
See [[microcode]] for information on how to install important security updates for your CPU's microcode.<br />
<br />
=== Disable hyper-threading ===<br />
<br />
If your computer contains an [[Intel]] CPU, disabling [[Wikipedia: Hyper-threading|hyper-threading]] is a security consideration due to [[Wikipedia:Microarchitectural Data Sampling|Microarchitectural Data Sampling]], see https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html. [https://www.youtube.com/watch?v=jI3YE3Jlgw8 Kernel developer Greg Kroah-Hartman has endorsed disabling hyper-threading] as a security hardening option for systems running untrusted code, such as web browsers that enable Javascript.<br />
<br />
To check if you are affected, run the following:<br />
<br />
$ grep . -r /sys/devices/system/cpu/vulnerabilities/<br />
<br />
If the output contains {{ic|SMT vulnerable}}, you should disable hyper-threading. Note that there will be a performance impact and you should consider if the trade-off is acceptable.<br />
<br />
Hyper-threading can often be disabled in your system's firmware. Consult your motherboard or system documentation for more information. You can also disable hyper-threading in the kernel by adding the following [[kernel parameters]]:<br />
<br />
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force<br />
<br />
Reboot afterwards and verify the output of grep. It should now say {{ic|SMT disabled}}.<br />
<br />
=== CPU vulnerabilities ===<br />
<br />
{{Expansion|Give a good set of defaults, plus discussion of the tradeoffs involved.}}<br />
<br />
In the wake of the Spectre/Meltdown vulnerabilities, certain configurable mitigations have been added to the kernel. Refer to the [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation] for more details.<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 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}}. For example, {{ic|man}} fails to work properly unless its {{ic|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 />
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 />
=== 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 />
== 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|2=<br />
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=<br />
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. Alternatively, use [[Wayland]] instead of Xorg.<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 is 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|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|<br />
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 />
How ever, 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 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/51-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
{{Tip|This is enabled by default in {{pkg|linux-hardened}}.}}<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://www.kernel.org/doc/html/latest/admin-guide/sysctl/net.html kernel documentation] for more details.<br />
<br />
{{Tip|{{pkg|linux-hardened}} sets {{ic|1=net.core.bpf_jit_harden=2}} by default rather than {{ic|0}}.}}<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama [[Wikipedia:Linux Security Modules|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}} [[Capabilities|capability]]. 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 />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<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 />
=== 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 in https://www.kernel.org/doc/html/latest/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://www.kernel.org/doc/html/latest/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, check it by running {{ic|cat /sys/kernel/security/lsm}}. If the output does not have {{ic|lockdown}} in it, set the [[kernel parameter]] {{ic|1=lsm=lockdown,yama}} and reboot.<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 />
== 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) 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 />
<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 />
=== 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 is 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 {{ic|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 />
== 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/]{{Dead link|2020|04|03|status=SSL error}} 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 />
[[#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 />
=== 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|locking down the boot loader]].<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 />
== 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. 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 />
== 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-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>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=GRUB&diff=626818GRUB2020-07-25T20:45:06Z<p>Phil.r.dubois: /* Installation */ Made note about full EFI entries</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[Category:GNU]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fa:گراب]]<br />
[[fr:GRUB]]<br />
[[he:GRUB]]<br />
[[id:GRUB]]<br />
[[it:GRUB]]<br />
[[ja:GRUB]]<br />
[[nl:GRUB]]<br />
[[pt:GRUB]]<br />
[[ru:GRUB]]<br />
[[zh-hans:GRUB]]<br />
[[zh-hant:GRUB]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|GRUB/EFI examples}}<br />
{{Related|GRUB/Tips and tricks}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) is a [[Boot loader|multi-boot loader]]. It is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the replacement of what is now known as [[GRUB Legacy]]. The latter had become too difficult to maintain and GRUB was rewritten from scratch with the aim to provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1]. The current GRUB is also referred to as GRUB 2 while GRUB Legacy corresponds to versions 0.9x.<br />
<br />
{{Note|In the entire article {{ic|''esp''}} denotes the mountpoint of the [[EFI system partition]] aka ESP.}}<br />
<br />
== BIOS systems ==<br />
<br />
=== GUID Partition Table (GPT) specific instructions ===<br />
<br />
On a BIOS/[[GPT]] configuration, a [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note|<br />
* Before attempting this method keep in mind that not all systems will be able to support this partitioning scheme. Read more on [[Partitioning#GUID Partition Table]].<br />
* The BIOS boot partition is only needed by GRUB on a BIOS/GPT setup. On a BIOS/MBR setup, GRUB uses the post-MBR gap for the embedding the {{ic|core.img}}. On GPT, however, there is no guaranteed unused space before the first partition.<br />
* For [[UEFI]] systems this extra partition is not required, since no embedding of boot sectors takes place in that case. However, UEFI systems still require an [[EFI system partition]].<br />
}}<br />
<br />
Create a mebibyte partition ({{ic|1=+1M}} with ''fdisk'' or ''gdisk'') on the disk with no file system and with partition type GUID {{ic|21686148-6449-6E6F-744E-656564454649}}.<br />
<br />
* Select partition type {{ic|BIOS boot}} for [[fdisk]].<br />
* Select partition type code {{ic|ef02}} for [[gdisk]].<br />
* For [[parted]] set/activate the flag {{ic|bios_grub}} on the partition.<br />
<br />
This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before GRUB installation. When the partition is ready, install the bootloader as per the instructions below.<br />
<br />
The space before the first partition can also be used as the BIOS boot partition though it will be out of GPT alignment specification. Since the partition will not be regularly accessed performance issues can be disregarded, though some disk utilities will display a warning about it. In ''fdisk'' or ''gdisk'' create a new partition starting at sector 34 and spanning to 2047 and set the type. To have the viewable partitions begin at the base consider adding this partition last.<br />
<br />
=== Master Boot Record (MBR) specific instructions ===<br />
<br />
Usually the post-MBR gap (after the 512 byte [[MBR]] region and before the start of the first partition) in many MBR partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{Bug|24103}}). It is advisable to use a partitioning tool that supports 1 MiB [[Partitioning#Partition alignment|partition alignment]] to obtain this space as well as to satisfy other non-512-byte-sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|grub}} package. (It will replace {{AUR|grub-legacy}} if that is already installed.) Then do:<br />
<br />
# grub-install --target=i386-pc ''/dev/sdX''<br />
<br />
where {{ic|''/dev/sdX''}} is the '''disk''' ('''not a partition''') where GRUB is to be installed. For example {{ic|/dev/sda}} or {{ic|/dev/nvme0n1}}, or {{ic|/dev/mmcblk0}}. See [[Device file#Block device names]] for a description of the block device naming scheme.<br />
<br />
Now you must [[#Generate the main configuration file|generate the main configuration file]].<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
{{Tip|See [[GRUB/Tips and tricks#Alternative installation methods]] for other ways to install GRUB, such as to a USB stick.}}<br />
<br />
See {{man|8|grub-install}} and [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] for more details on the {{ic|grub-install}} command.<br />
<br />
== UEFI systems ==<br />
<br />
{{Note|<br />
* It is recommended to read and understand the [[Unified Extensible Firmware Interface]], [[Partitioning#GUID Partition Table]] and [[Arch boot process#Under UEFI]] pages.<br />
* When installing to use UEFI it is important to boot the installation media in UEFI mode, otherwise ''efibootmgr'' will not be able to add the GRUB UEFI boot entry. Installing to the [[#Default/fallback boot path|fallback boot path]] will still work even in BIOS mode since it does not touch the NVRAM.<br />
* To boot from a disk using UEFI, an EFI system partition is required. Follow [[EFI system partition#Check for an existing partition]] to find out if you have one already, otherwise you need to create it.<br />
}}<br />
<br />
=== Installation ===<br />
<br />
{{Note|<br />
* UEFI firmwares are not implemented consistently across manufacturers. The procedure described below is intended to work on a wide range of UEFI systems but those experiencing problems despite applying this method are encouraged to share detailed information, and if possible the workarounds found, for their hardware-specific case. A [[GRUB/EFI examples]] article has been provided for such cases.<br />
* The section assumes you are installing GRUB for x86_64 systems. For IA32 (32-bit) UEFI systems (not to be confused with 32-bit CPUs), replace {{ic|x86_64-efi}} with {{ic|i386-efi}} where appropriate.<br />
}}<br />
<br />
First, [[install]] the packages {{Pkg|grub}} and {{Pkg|efibootmgr}}: ''GRUB'' is the bootloader while ''efibootmgr'' is used by the GRUB installation script to write boot entries to NVRAM.<br />
<br />
Then follow the below steps to install GRUB:<br />
<br />
# [[EFI system partition#Mount the partition|Mount the EFI system partition]] and in the remainder of this section, substitute {{ic|''esp''}} with its mount point.<br />
# Choose a bootloader identifier, here named {{ic|GRUB}}. A directory of that name will be created in {{ic|''esp''/EFI/}} to store the EFI binary and this is the name that will appear in the UEFI boot menu to identify the GRUB boot entry.<br />
# Execute the following command to install the GRUB EFI application {{ic|grubx64.efi}} to {{ic|''esp''/EFI/GRUB/}} and install its modules to {{ic|/boot/grub/x86_64-efi/}}.<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB<br />
<br />
After the above install completed the main GRUB directory is located at {{ic|/boot/grub/}}. Note that {{ic|grub-install}} also tries to [[GRUB/Tips and tricks#Create a GRUB entry in the firmware boot manager|create an entry in the firmware boot manager]], named {{ic|GRUB}} in the above example -- this will, however, fail if your boot entries are full; use efibootmgr to remove unnecessary entries.<br />
<br />
Remember to [[#Generate the main configuration file]] after finalizing the configuration.<br />
<br />
{{Tip|If you use the option {{ic|--removable}} then GRUB will be installed to {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} (or {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} for the {{ic|i386-efi}} target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually places an EFI executable there, but its only purpose is to recreate the UEFI boot entry for Windows.}}<br />
<br />
{{Note|<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI, {{ic|--efi-directory}} replaces {{ic|--root-directory}} which is deprecated. <br />
* You might note the absence of a ''device_path'' option (e.g.: {{ic|/dev/sda}}) in the {{ic|grub-install}} command. In fact any ''device_path'' provided will be ignored by the GRUB UEFI install script. Indeed, UEFI bootloaders do not use a MBR bootcode or partition boot sector at all.<br />
* Make sure to run the {{ic|grub-install}} command from the system in which GRUB will be installed as the boot loader. That means if you are booting from the live installation environment, you need to be inside the chroot when running {{ic|grub-install}}. If for some reason it is necessary to run {{ic|grub-install}} from outside of the installed system, append the {{ic|1=--boot-directory=}} option with the path to the mounted {{ic|/boot}} directory, e.g {{ic|1=--boot-directory=/mnt/boot}}.<br />
}}<br />
<br />
See [[#UEFI|UEFI troubleshooting]] in case of problems. Additionally see [[GRUB/Tips and tricks#UEFI further reading]].<br />
<br />
== Configuration ==<br />
<br />
On an installed system, GRUB loads the {{ic|/boot/grub/grub.cfg}} configuration file each boot. You can follow [[#Generated grub.cfg]] for using a tool, or [[#Custom grub.cfg]] for a manual creation.<br />
<br />
=== Generated grub.cfg ===<br />
<br />
This section only covers editing the {{ic|/etc/default/grub}} configuration file. See [[GRUB/Tips and tricks]] for more information.<br />
<br />
{{Note|Remember to always [[#Generate the main configuration file|generate the main configuration file]] after making changes to {{ic|/etc/default/grub}} and/or files in {{ic|/etc/grub.d/}}.}}<br />
<br />
==== Generate the main configuration file ====<br />
<br />
After the installation, the main configuration file {{ic|/boot/grub/grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}. <br />
<br />
If you have not done additional configuration, the automatic generation will determine the root filesystem of the system to boot for the configuration file. For that to succeed it is important that the system is either booted or chrooted into. <br />
<br />
{{Note|1=<nowiki></nowiki><br />
* The default file path is {{ic|/boot/grub/grub.cfg}}, not {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a [[chroot]] or [[systemd-nspawn]] container, you might notice that it does not work: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}. In this case, try using [[arch-chroot]] as described in the [https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 BBS post].<br />
* If you are installing GRUB in chroot environment using LVM and the {{ic|grub-mkconfig}} hangs indefinitely, see [[#Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds]].<br />
}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|/boot/grub/grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
By default the generation scripts automatically add menu entries for all installed Arch Linux [[kernel]]s to the generated configuration.<br />
<br />
{{Tip|<br />
* After installing or removing a [[kernel]], you just need to re-run the above ''grub-mkconfig'' command.<br />
* For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[GRUB/Tips and tricks#Multiple entries]].<br />
}}<br />
<br />
To automatically add entries for other installed operating systems, see [[#Detecting other operating systems]]. <br />
<br />
You can add additional custom menu entries by editing {{ic|/etc/grub.d/40_custom}} and re-generating {{ic|/boot/grub/grub.cfg}}. Or you can create {{ic|/boot/grub/custom.cfg}} and add them there. Changes to {{ic|/boot/grub/custom.cfg}} do not require re-running ''grub-mkconfig'', since {{ic|/etc/grub.d/41_custom}} adds the necessary {{ic|source}} statement to the generated configuration file.<br />
<br />
{{Tip|{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/''nn''_custom}}, where {{ic|''nn''}} defines the precedence, indicating the order the script is executed. The order scripts are executed determine the placement in the GRUB boot menu. {{ic|''nn''}} should be greater than {{ic|06}} to ensure necessary scripts are executed first.}}<br />
<br />
See [[#Boot menu entry examples]] for custom menu entry examples.<br />
<br />
==== Detecting other operating systems ====<br />
<br />
To have ''grub-mkconfig'' search for other installed systems and automatically add them to the menu, [[install]] the {{Pkg|os-prober}} package and [[mount]] the partitions that contain the other systems. Then re-run ''grub-mkconfig''.<br />
<br />
===== MS Windows =====<br />
<br />
Often, partitions containing Windows will be automatically discovered by {{Pkg|os-prober}}. However, NTFS partitions may not always be detected when mounted with the default Linux drivers. If GRUB is not detecting it, try installing [[NTFS-3G]] and remounting.<br />
<br />
Encrypted Windows partitions may need to be decrypted before mounting. For BitLocker, this can be done with {{AUR|dislocker}}. This should be sufficient for {{Pkg|os-prober}} to add the correct entry.<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation.<br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|1=GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=''uuid-of-swap-partition'' quiet"}} where {{ic|''uuid-of-swap-partition''}} is the [[UUID]] of your swap partition to enable resume after [[hibernation]]. This would generate a recovery boot entry without the resume and without {{ic|quiet}} suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options.<br />
<br />
By default ''grub-mkconfig'' determines the [[UUID]] of the root filesystem for the configuration. To disable this, uncomment {{ic|1=GRUB_DISABLE_LINUX_UUID=true}}. <br />
<br />
For generating the GRUB recovery entry you have to ensure that {{ic|GRUB_DISABLE_RECOVERY}} is not set to {{ic|true}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
==== LVM ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|lvm}} module, specifying it in {{ic|GRUB_PRELOAD_MODULES}} is not required. Move warning to [[#Installation]] & [[#Installation_2]] or create a [[Help:Style#"Known issues" section|Known issues section]] and document it there.}}<br />
<br />
{{Warning|GRUB does not support thin-provisioned logical volumes.}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}} or {{ic|/}} root partition, make sure that the {{ic|lvm}} module is preloaded:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... lvm"<br />
}}<br />
<br />
==== RAID ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|mdraid09}} and/or {{ic|mdraid1x}} modules, specifying them in {{ic|GRUB_PRELOAD_MODULES}} is not required. Summarize the double grub-install in a note and move it to [[#Installation]]; move {{ic|set root}} stuff to [[#Custom grub.cfg]].}}<br />
<br />
GRUB provides convenient handling of [[RAID]] volumes. You need to load GRUB modules {{ic|mdraid09}} or {{ic|mdraid1x}} to allow you to address the volume natively:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... mdraid09 mdraid1x"<br />
}}<br />
<br />
For example, {{ic|/dev/md0}} becomes:<br />
<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on BIOS systems, simply run ''grub-install'' on both of the drives, such as:<br />
<br />
# grub-install --target=i386-pc --debug /dev/sda<br />
# grub-install --target=i386-pc --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
{{Note|GRUB supports booting from [[Btrfs]] RAID 0/1/10, but ''not'' RAID 5/6. You may use [[mdadm]] for RAID 5/6, which is supported by GRUB.}}<br />
<br />
==== Encrypted /boot ====<br />
<br />
GRUB also has special support for booting with an encrypted {{ic|/boot}}. This is done by unlocking a [[LUKS]] blockdevice in order to read its configuration and load any [[initramfs]] and [[kernel]] from it. This option tries to solve the issue of having an [[dm-crypt/Specialties#Securing the unencrypted_boot partition|unencrypted boot partition]].<br />
<br />
{{Note|{{ic|/boot}} is '''not''' required to be kept in a separate partition; it may also stay under the system's root {{ic|/}} directory tree.}}<br />
<br />
{{Warning|GRUB only supports LUKS2 headers (but not with Argon2i or Argon2id PBKDFs) in git master; see [https://savannah.gnu.org/bugs/?55093 GRUB bug #55093]. Make sure to specify {{ic|1=--type luks1}} when creating the encrypted partition using {{ic|cryptsetup luksFormat}}.}}<br />
<br />
To enable this feature encrypt the partition with {{ic|/boot}} residing on it using [[LUKS]] as normal. Then add the following option to {{ic|/etc/default/grub}}:<br />
<br />
{{hc|/etc/default/grub|output=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
This option is used by grub-install to generate the grub {{ic|core.img}}, so make sure to [[#Installation|install grub]] after modifying this option.<br />
<br />
Without further changes you will be prompted twice for a passhrase: the first for GRUB to unlock the {{ic|/boot}} mount point in early boot, the second to unlock the root filesystem itself as implemented by the initramfs. You can use a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]] to avoid this.<br />
<br />
{{Warning|<br />
* If you want to [[#Generate the main configuration file|generate the main configuration file]], make sure that {{ic|/boot}} is mounted.<br />
* In order to perform system updates involving the {{ic|/boot}} mount point, ensure that the encrypted {{ic|/boot}} is unlocked and mounted before performing an update. With a separate {{ic|/boot}} partition, this may be accomplished automatically on boot by using [[crypttab]] with a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]].<br />
}}<br />
<br />
{{Note|<br />
* If you use a special keymap, a default GRUB installation will not know it. This is relevant for how to enter the passphrase to unlock the LUKS blockdevice. See [[GRUB/Tips and tricks#Manual configuration of core image for early boot]].<br />
* If you experience issues getting the prompt for a password to display (errors regarding cryptouuid, cryptodisk, or "device not found"), try reinstalling GRUB and appending {{ic|1=--modules="part_gpt part_msdos"}} to the end of your {{ic|grub-install}} command.<br />
}}<br />
<br />
{{Tip|1=You can use [https://bbs.archlinux.org/viewtopic.php?id=234607 pacman hooks] to automount your {{ic|/boot}} when upgrades need to access related files.}}<br />
<br />
=== Custom grub.cfg ===<br />
<br />
{{Expansion|Add instructions on how to write a custom {{ic|/boot/grub/grub.cfg}}. See [[User:Eschwartz/Grub]] for a proposed draft.|section=Manually generate grub.cfg}}<br />
<br />
This section describes the manual creation of GRUB boot entries in {{ic|/boot/grub/grub.cfg}} instead of relying on ''grub-mkconfig''.<br />
<br />
A basic GRUB config file uses the following options:<br />
<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
==== Boot menu entry examples ====<br />
<br />
{{Tip|These boot entries can also be used when using a {{ic|/boot/grub/grub.cfg}} generated by ''grub-mkconfig''. Add them to {{ic|/etc/grub.d/40_custom}} and [[#Generate the main configuration file|re-generate the main configuration file]] or add them to {{ic|/boot/grub/custom.cfg}}.}}<br />
<br />
For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[GRUB/Tips and tricks#Multiple entries]].<br />
<br />
For [[Archiso]] and [[Archboot]] boot menu entries see [[Multiboot USB drive#Boot entries]].<br />
<br />
===== GRUB commands =====<br />
<br />
====== "Shutdown" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
}}<br />
<br />
====== "Restart" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}<br />
}}<br />
<br />
====== "Firmware setup" menu entry (UEFI only) ======<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
menuentry "Firmware setup" {<br />
fwsetup<br />
}<br />
fi<br />
}}<br />
<br />
===== EFI binaries =====<br />
<br />
When launched in UEFI mode, GRUB can chainload other EFI binaries.<br />
<br />
{{Tip|1=To show these menu entries only when GRUB is launched in UEFI mode, enclose them in the following {{ic|if}} statement:<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
''place UEFI-only menu entries here''<br />
fi<br />
}}<br />
<br />
}}<br />
<br />
====== UEFI Shell ======<br />
<br />
You can launch [[Unified Extensible Firmware Interface#UEFI Shell|UEFI Shell]] by placing it in the root of the [[EFI system partition]] and adding this menu entry:<br />
<br />
{{bc|1=<br />
menuentry "UEFI Shell" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /shellx64.efi<br />
chainloader /shellx64.efi<br />
}<br />
}}<br />
<br />
====== gdisk ======<br />
<br />
Download the [[gdisk#gdisk EFI application|gdisk EFI application]] and copy {{ic|gdisk_x64.efi}} to {{ic|''esp''/EFI/tools/}}.<br />
<br />
{{bc|1=<br />
menuentry "gdisk" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi<br />
chainloader /EFI/tools/gdisk_x64.efi<br />
}<br />
}}<br />
<br />
====== Chainloading a unified kernel image ======<br />
<br />
If you have a [[unified kernel image]] generated from following [[Secure Boot]] or other means, you can add it to the boot menu. For example:<br />
<br />
{{bc|1=<br />
menuentry "Arch Linux" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''<br />
chainloader /EFI/Linux/Arch-linux.efi<br />
}<br />
}}<br />
<br />
===== Dual-booting =====<br />
<br />
====== GNU/Linux ======<br />
<br />
Assuming that the other distribution is on partition {{ic|sda2}}:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
Alternatively let GRUB search for the right partition by UUID or file system label:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
# assuming that UUID is 763A-9CB6<br />
search --no-floppy --set=root --fs-uuid 763A-9CB6<br />
<br />
# search by label OTHER_LINUX (make sure that partition label is unambiguous)<br />
#search --no-floppy --set=root --label OTHER_LINUX<br />
<br />
linux /boot/vmlinuz (add other options here as required, for example: root=UUID=763A-9CB6)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
If the other distribution has already a valid {{ic|/boot}} folder with installed GRUB, {{ic|grub.cfg}}, kernel and initramfs, GRUB can be instructed to load these other {{ic|grub.cfg}} files on-the-fly during boot. For example, for {{ic|hd0}} and the fourth GPT partition:<br />
<br />
{{bc|1=<br />
menuentry "configfile hd0,gpt4" {<br />
insmod part_gpt<br />
insmod btrfs<br />
insmod ext2<br />
set root='hd0,gpt4'<br />
configfile /boot/grub/grub.cfg<br />
}<br />
}}<br />
<br />
When choosing this entry, GRUB loads the {{ic|grub.cfg}} file from the other volume and displays that menu. Any environment variable changes made by the commands in file will not be preserved after {{ic|configfile}} returns. Press {{ic|Esc}} to return to the first GRUB menu.<br />
<br />
====== Windows installed in UEFI/GPT mode ======<br />
<br />
This mode determines where the Windows bootloader resides and chain-loads it after GRUB when the menu entry is selected. The main task here is finding the EFI system partition and running the bootloader from it.<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the UEFI bitness. It will not work in BIOS installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] for more information.}}<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi<br />
}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. <br />
<br />
The {{ic|$fs_uuid}} command determines the UUID of the EFI system partition:<br />
<br />
{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
1ce5-7f28<br />
}}<br />
<br />
Alternatively one can run {{ic|blkid}} (as root) and read the UUID of the EFI system partition from there.<br />
<br />
The {{ic|$hints_string}} command will determine the location of the EFI system partition, in this case harddrive 0:<br />
<br />
{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1<br />
}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|''esp''}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
====== Windows installed in BIOS/MBR mode ======<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading chainloading] of partition boot sector is no longer required to boot Windows in a BIOS/MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually {{ic|C:}}). The system partition's [[Persistent block device naming#by-label|filesystem label]] is {{ic|System Reserved}} or {{ic|SYSTEM}} and the partition is only about 100 to 549 MiB in size. See [[Wikipedia:System partition and boot partition]] for more information.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of {{ic|hd0,msdos1}}.<br />
<br />
{{Note|These menu entries will work only in BIOS boot mode. It will not work in UEFI installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] .}}<br />
<br />
In both examples {{ic|''XXXXXXXXXXXXXXXX''}} is the filesystem UUID which can be found with command {{ic|lsblk --fs}}.<br />
<br />
For Windows Vista/7/8/8.1/10:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr <br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /bootmgr<br />
}<br />
fi<br />
}}<br />
<br />
For Windows XP:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr <br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /ntldr<br />
}<br />
fi<br />
}}<br />
<br />
{{Note|In some cases, GRUB may be installed without a clean Windows 8, in which case you cannot boot Windows without having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it by going to Windows Recovery Console ({{ic|cmd.exe}} from install disk) and executing:<br />
<br />
X:\> bootrec.exe /fixboot<br />
X:\> bootrec.exe /RebuildBcd<br />
<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.<br />
Or you can use Boot Repair function in the Troubleshooting menu - it will not wipe out GRUB but will fix most errors.<br />
Also you would better keep plugged in both the target hard drive and your bootable device '''ONLY'''. Windows usually fails to repair boot information if any other devices are connected.<br />
}}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub/}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
<br />
grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub><br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the start of a partitioned disk (MBR), at the start of a partition or a partitionless disk (VBR), or as an EFI binary in the case of UEFI.<br />
<br />
==== Chainloading a partition's VBR ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partition of the first hard disk,<br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk's MBR or a partitionless disk's VBR ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod fat<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
{{ic|insmod fat}} is used for loading the FAT file system module for accessing the Windows bootloader on the EFI system partition.<br />
{{ic|(hd0,gpt4)}} or {{ic|/dev/sda4}} is the EFI system partition in this example.<br />
The entry in the {{ic|chainloader}} line specifies the path of the ''.efi'' file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[#Using the rescue console]]<br />
<br />
=== Using the rescue console ===<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hd''X'',''Y'')/boot/grub<br />
<br />
where {{ic|''X''}} is the physical drive number and {{ic|''Y''}} is the partition number.<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path (i.e. type {{ic|1=set prefix=(hd''X'',''Y'')/grub}}).}}<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
or simply<br />
<br />
grub rescue> insmod linux<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar.<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using UEFI), again change the lines accordingly: <br />
<br />
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}<br />
<br />
set root=(hd0,5)<br />
linux (hd''X'',''Y'')/vmlinuz-linux root=/dev/sda6<br />
initrd (hd''X'',''Y'')/initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== GRUB removal ==<br />
<br />
{{Expansion|Migrating from BIOS booting to UEFI is not the only case where GRUB could be removed. Section needs to either cover how to remove GRUB installed for UEFI booting or it should be removed altogether as too trivial.}}<br />
<br />
After migrating to GPT/UEFI one may want to remove the [[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]] [[dd#Remove bootloader|using dd]]:<br />
<br />
# dd if=/dev/zero of=/dev/sd''X'' bs=440 count=1<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unsupported file systems ===<br />
<br />
In case that GRUB does not support the root file system, an alternative {{ic|/boot}} partition with a supported file system must be created. In some cases, the development version of GRUB {{aur|grub-git}} may have native support for the file system.<br />
<br />
If GRUB is used with an unsupported file system it is not able to extract the [[UUID]] of your drive so it uses classic non-persistent {{ic|/dev/''sdXx''}} names instead. In this case you might have to manually edit {{ic|/boot/grub/grub.cfg}} and replace {{ic|1=root=/dev/''sdXx''}} with {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}}. You can use the {{ic|blkid}} command to get the UUID of your device, see [[Persistent block device naming]].<br />
<br />
=== Intel BIOS not booting GPT ===<br />
<br />
{{Move|Arch boot process#Troubleshooting|The issue is not limited to GRUB nor to just GPT.}}<br />
<br />
{{Accuracy|There would be no "1007 KiB partition" in a GPT disk's protective MBR unless hybrid-MBR was used and there is no reason to assume that it would. On GPT, by default, there is only one partition in the protective MBR—{{ic|0xEE}}—which, although violates the specification, can be marked bootable using ''fdisk'' or ''parted''.}}<br />
<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
With cfdisk, the steps are similar, just {{ic|cfdisk /dev/sda}}, choose bootable (at the left) in the desired hard disk, and quit saving.<br />
<br />
With recent version of parted, you can use {{ic|disk_toggle pmbr_boot}} option. Afterwards verify that Disk Flags show pmbr_boot.<br />
<br />
# parted /dev/sd''x'' disk_toggle pmbr_boot<br />
# parted /dev/sd''x'' print<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
=== Enable debug messages ===<br />
<br />
{{Note|This change is overwritten when [[#Generate the main configuration file]].}}<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== UEFI ===<br />
<br />
==== Common installation errors ====<br />
<br />
* If you have a problem when running ''grub-install'' with ''sysfs'' or ''procfs'' and it says you must run {{ic|modprobe efivarfs}}, try [[Unified Extensible Firmware Interface#Mount efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* If after running grub-install you are told your partition does not look like an EFI partition then the partition is most likely not {{ic|Fat32}}.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{Expansion|Provide an efibootmgr command.}}<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== Drop to rescue shell ====<br />
<br />
If GRUB loads but drops into the rescue shell with no errors, it can be due to one of these two reasons:<br />
<br />
* It may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing,<br />
* It also happens if the boot partition, which is hardcoded into the {{ic|grubx64.efi}} file, has changed.<br />
<br />
==== GRUB UEFI not loaded ====<br />
<br />
An example of a working UEFI:<br />
<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EFI\GRUB\grubx64.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\shellx64.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grubx64.efi)<br />
<br />
==== Default/fallback boot path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to install GRUB at the default/fallback boot path:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''<br />
<br />
Alternatively you can move an already installed GRUB EFI executable to the default/fallback path:<br />
<br />
# mv ''esp''/EFI/grub ''esp''/EFI/BOOT<br />
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions may have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}}.<br />
<br />
=== Warning when installing in chroot ===<br />
<br />
When installing GRUB on a LVM system in a chroot environment (e.g. during system installation), you may receive warnings like<br />
<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
<br />
or<br />
<br />
WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.<br />
<br />
This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
<br />
=== GRUB loads slowly ===<br />
<br />
GRUB can take a long time to load when disk space is low. Check if you have sufficient free disk space on your {{ic|/boot}} or {{ic|/}} partition when you are having problems.<br />
<br />
=== error: unknown filesystem ===<br />
<br />
GRUB may output {{ic|error: unknown filesystem}} and refuse to boot for a few reasons. If you are certain that all [[UUID]]s are correct and all filesystems are valid and supported, it may be because your [[#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] is located outside the first 2 TiB of the drive [https://bbs.archlinux.org/viewtopic.php?id=195948]. Use a partitioning tool of your choice to ensure this partition is located fully within the first 2 TiB, then reinstall and reconfigure GRUB.<br />
<br />
This error might also be caused by an [[ext4]] filesystem having the features {{ic|large_dir}} or {{ic|metadata_csum_seed}} set.<br />
<br />
=== grub-reboot not resetting ===<br />
<br />
GRUB seems to be unable to write to root BTRFS partitions [https://bbs.archlinux.org/viewtopic.php?id=166131]. If you use grub-reboot to boot into another entry it will therefore be unable to update its on-disk environment. Either run grub-reboot from the other entry (for example when switching between various distributions) or consider a different file system. You can reset a "sticky" entry by executing {{ic|grub-editenv create}} and setting {{ic|1=GRUB_DEFAULT=0}} in your {{ic|/etc/default/grub}} (do not forget {{ic|grub-mkconfig -o /boot/grub/grub.cfg}}).<br />
<br />
=== Old BTRFS prevents installation ===<br />
<br />
If a drive is formatted with BTRFS without creating a partition table (eg. /dev/sdx), then later has partition table written to, there are parts of the BTRFS format that persist. Most utilities and OS's do not see this, but GRUB will refuse to install, even with --force<br />
<br />
# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..<br />
# grub-install: error: filesystem `btrfs' does not support blocklists.<br />
<br />
You can zero the drive, but the easy solution that leaves your data alone is to erase the BTRFS superblock with {{ic|wipefs -o 0x10040 /dev/sdx}}<br />
<br />
=== Windows 8/10 not found ===<br />
<br />
A setting in Windows 8/10 called "Hiberboot", "Hybrid Boot" or "Fast Boot" can prevent the Windows partition from being mounted, so {{ic|grub-mkconfig}} will not find a Windows install. Disabling Hiberboot in Windows will allow it to be added to the GRUB menu.<br />
<br />
=== VirtualBox EFI mode ===<br />
<br />
For VirtualBox < 6.1, install GRUB to the [[#Default/fallback boot path|default/fallback boot path]].<br />
<br />
See also [[VirtualBox#Installation in EFI mode on VirtualBox < 6.1]].<br />
<br />
=== Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds ===<br />
<br />
If grub-mkconfig hangs and gives error: {{ic|WARNING: Device /dev/''xxx'' not initialized in udev database even after waiting 10000000 microseconds}}.<br />
<br />
You may need to provide {{ic|/run/lvm/}} access to the chroot environment using:<br />
<br />
# mkdir /mnt/hostlvm<br />
# mount --bind /run/lvm /mnt/hostlvm<br />
# arch-chroot /mnt<br />
# ln -s /hostlvm /run/lvm<br />
<br />
See {{Bug|61040}} and [https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949 workaround].<br />
<br />
=== GRUB rescue and encrypted /boot ===<br />
<br />
When using an [[#Encrypted /boot|encrypted /boot]], and you fail to input a correct password, you will be dropped in grub-rescue prompt.<br />
<br />
This grub-rescue prompt has limited capabilities. Use the following commands to complete the boot:<br />
{{bc|<br />
grub rescue> cryptomount <partition><br />
grub rescue> insmod normal<br />
grub rescue> normal<br />
}}<br />
<br />
See [https://blog.stigok.com/2017/12/30/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html this blog post] for a better description.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:GNU GRUB]]<br />
* [https://www.gnu.org/software/grub/manual/grub.html Official GRUB Manual]<br />
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki page for GRUB]<br />
* [https://help.ubuntu.com/community/UEFIBooting GRUB wiki page describing steps to compile for UEFI systems]<br />
* [[Wikipedia:BIOS Boot partition]]<br />
* [http://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme How to configure GRUB]<br />
* [https://forum.manjaro.org/t/detecting-efi-files-and-booting-them-from-grub/38083 Detecting efi files and booting them from grub]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Chrome_OS_devices&diff=597542Chrome OS devices2020-02-15T04:57:54Z<p>Phil.r.dubois: /* Fixing audio */ Note that alsactl is part of the alsa-utils package.</p>
<hr />
<div>[[Category:Laptops]]<br />
[[ja:Chrome OS デバイス]]<br />
{{Related articles start}}<br />
{{Related|Chrome OS devices/Crostini}}<br />
{{Related|Chrome OS devices/Chromebook}}<br />
{{Related|Chrome OS devices/Custom firmware}}<br />
{{Related|Installation guide}}<br />
{{Related|Laptop}}<br />
{{Related articles end}}<br />
{{Warning|This article relies on third-party scripts and modifications, and may irreparably damage your hardware or data. Proceed at your own risk.}}<br />
This article was created to provide information on how to get Arch installed on the series of Chrome OS devices built by Acer, HP, Samsung, Toshiba, and Google. Currently this page is being overhauled, and more model specific pages are being built with some of the information listed below. <br />
<br />
{{Note|This article describes how to install Arch Linux by activating developer mode. For instructions on how to install Arch Linux in a ChromeOS container without having to enable developer mode see [[Crostini]]}}<br />
<br />
== Introduction ==<br />
<br />
=== Legacy Boot Mode ===<br />
<br />
All recent Intel-based Chrome OS devices (starting with the 2013 Chromebook Pixel) feature a Legacy Boot Mode, designed to allow the user to boot Linux. Legacy Boot Mode has a dedicated firmware region, {{ic|RW_LEGACY}}, which is designed to be user-writeable (hence the 'RW' notation) and is completely separate from the ChromeOS portion of the firmware (ie, it is safe to update and cannot brick the device). It is enabled by the [http://www.coreboot.org/SeaBIOS SeaBIOS] payload of [http://www.coreboot.org/ coreboot], the open-source firmware used for all Chrome OS devices (with the exception of the first generation of Chromebooks and a few early ARM models). SeaBIOS behaves like a traditional BIOS that boots into the MBR of the disk, and from there into standard bootloaders like Syslinux and GRUB.<br />
<br />
Models with a Core-i based SoC (Haswell, Broadwell, Skylake, KabyLake) mostly ship with a functional Legacy Boot Mode payload; updating to a 3rd party build can provide bug fixes and additional features. Models with an Atom-based SoC (Baytrail, Braswell, Apollolake) have Legacy Boot Mode capability, but do not ship with a RW_LEGACY/SeaBIOS payload (that part of the firmware is blank). These models require a 3rd party RW_LEGACY firmware to be loaded for Legacy Boot Mode to be functional.<br />
<br />
<br />
==== Models without Legacy Boot Mode/SeaBIOS ====<br />
<br />
One of the following approaches can be taken in order to install Arch Linux on Chrome OS devices which did not ship with SeaBIOS as part of the installed firmware:<br />
<br />
* If the device supports Legacy Boot Mode, but does not ship with a functional {{ic|RW_LEGACY}} payload (or doesn't ship with one at all), one can flash a SeaBIOS payload to the {{ic|RW_LEGACY}} part of the firmware. This is 100% safe, as it writes to a user-writeable area of the firmware image which is completely separate from/does not affect ChromeOS. The easiest way to install/update the RW_LEGACY firmware on your ChromeOS device is via MrChromebox's [[Chrome_OS_devices/Custom_firmware#Flashing_with_MrChromebox.27s_Firmware_Utility_Script|Firmware Utility Script]], which supports the widest range of devices and offers the most up-to-date SeaBIOS builds; one can also update the {{ic|RW_LEGACY}} firmware manually with Chrome OS' {{ic|flashrom}} (requires downloading/compiling your own build), or use John Lewis' {{ic|flash_chromebook_rom.sh}} script (no longer supported).<br />
<br />
* Flash a full [[Custom firmware for Chrome OS devices|custom firmware]] which includes either a SeaBIOS or UEFI payload, and removes all the ChromeOS-specific parts.<br />
<br />
* Flash the {{ic|BOOT_STUB}} part of the firmware. This method replaces the stock ChromeOS payload (depthcharge) with SeaBIOS. This is theoretically a safer approach than flashing the full firmware but there might be some limitations (e.g. no support in suspend or VMX). This is the {{ic|Modify ROM to run SeaBIOS exclusively}} option in John Lewis' {{ic|flash_chromebook_rom.sh}} script and {{ic|Flash BOOT_STUB firmware}} option in MrChromebox's.<br />
<br />
* Take the ChrUbuntu approach which uses the Chrome OS kernel and modules.<br />
<br />
* Build and sign your own kernel, see [https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP] [http://pomozok.wordpress.com/2014/10/11/building-chromeos-kernel-without-chroot/] [https://github.com/drsn0w/chromebook_kernel_tools/blob/master/install_linux.md].<br />
<br />
The [[#Installation|Installation]] process described on this page tries to cover the method of installing Arch Linux on models without SeaBIOS by flashing a custom firmware.<br />
<br />
=== Firmware write protection intro ===<br />
<br />
All Chrome OS devices features firmware write protection, which restricts write access to certain regions of the flash chip. It is important to be aware of it as one might need to disable the hardware write protection as part of the installation process (to update GBB flags or flash a custom firmware).<br />
<br />
For more details see [[Custom firmware for Chrome OS devices#Firmware write protection|Firmware write protection]].<br />
<br />
=== Prerequisites ===<br />
<br />
* You should claim your free 100GB-1TB of Google Drive space before you install Arch. This needs to happen from ChromeOS(version > 23), not linux. This will sync/backup ChromeOS, as designed<br />
* Visit the ArchWiki page for your [[#Chrome OS devices|Chrome OS device]].<br />
* If there is no ArchWiki page for your device then before proceeding, gather information about the device and if you succeed in installing Arch Linux, then consider adding a new ArchWiki page for your model (you can use the [[Acer C720]] as an example for device shipped with SeaBios or the [[Acer_C710_Chromebook|Acer C710]] as device that did not ship with it).<br />
* Read this guide completely and make sure you understand all the steps before making any changes.<br />
<br />
== Chrome OS devices ==<br />
<br />
See [[Chrome_OS_devices/Chromebook|Chromebook models]] for hardware comparison with details about SeaBIOS availability and storage expansion.<br />
<br />
=== General hardware recommendations and remarks ===<br />
<br />
* MyDigitalSSD M.2 NGFF SSD drives are probably the most popular choice when upgrading the internal SSD of a Chrome OS device. There are multiple accounts of failing MyDigitalSSD SSD drives at the Acer C720 topic on the Arch forums [https://bbs.archlinux.org/viewtopic.php?pid=1461993#p1461993] [https://bbs.archlinux.org/viewtopic.php?pid=1474680#p1474680] [https://bbs.archlinux.org/viewtopic.php?pid=1460460#p1460460] and much more on the web. If the SSD was upgraded to a MyDigitalSSD model then it is highly recommended to backup the system and data frequently. It might be advisable to upgrade the SDD with a different brand. Notice that this might be due to a SSD firmware issue so updating the SSD firmware is highly recommended.<br />
* Transcend MTS400 M.2 NGFF SSD drives are failing (at least with stock Coreboot firmware) when ALPM is enabled, ATM there is no SSD firmware update that fixing this bug, so it is highly advisable to disabled ALPM if a power management daemon has been installed (which enabled it), see [[Solid_State_Drives#Resolving_SATA_power_management_related_errors|Resolving SATA power management related errors]] and [http://superuser.com/questions/887916/transcend-mts400-ssd-crashes-my-acer-c720-chromebook-how-to-disable-sata-power how to disable ALPM in Chrome OS].<br />
<br />
== Installation ==<br />
<br />
{{Warning|Installation on ChromeOS devices that do not ship with SeaBIOS requires flashing a custom firmware, certain types of which have the potential to brick your device. Proceed at your own risk.}}<br />
<br />
{{Note|While the following information should fit all the ChromeOS devices with coreboot firmware (shipped with SeaBIOS payload or without), it is possible that with some models you may need to make further adjustments.}}<br />
<br />
The general installation procedure:<br />
* Enable developer mode.<br />
* ChromeOS device with functional Legacy Boot Mode/SeaBIOS:<br />
** Enable Legacy Boot Mode.<br />
** Set SeaBIOS as default (optional but highly recommended, requires disabling the write protection).<br />
* ChromeOS device without functional Legacy Boot Mode:<br />
** Flash one of the following types of custom firmware<br />
*** Flash RW_LEGACY firmware (zero risk)<br />
*** Flash BOOT_STUB firmware (very low risk).<br />
*** Flash Full custom firmware (low risk).<br />
* Prepare the installation media.<br />
* Boot Arch Linux installation media and install Arch.<br />
<br />
=== Enabling developer mode ===<br />
<br />
[http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-c720-chromebook#TOC-Developer-Mode Developer Mode] is necessary in order to access the superuser shell inside ChromeOS, which is required for making changes to the system like allow booting through SeaBIOS.<br />
<br />
{{Warning|Enabling Developer Mode will wipe all of your data.}}<br />
<br />
To enable developer mode: <br />
<br />
* Press and hold the {{ic|Esc + F3 (Refresh)}} keys, then press the {{ic|Power}} button. This enters Recovery Mode.<br />
** Chromeboxes have a dedicated Recovery button, which should be pressed/held while powering on<br />
* Press {{ic|Ctrl + D}} (no prompt). It will ask you to confirm, then the system will revert its state and enable Developer Mode.<br />
{{Note|Press {{ic|Ctrl + D}} (or wait 30 seconds for the beep and boot) at the white boot splash screen to enter ChromeOS.}}<br />
<br />
=== Accessing the superuser shell ===<br />
<br />
After you have enabled the Developer Mode you will need to access the superuser shell. How you do this depends on whether you have configured ChromeOS or not.<br />
<br />
==== Accessing the superuser shell without logging into ChromeOS ====<br />
<br />
If you have not configured ChromeOS, just press {{ic|Ctrl + Alt + F2}} (F2 is the "forward" arrow on the top row, →), you will see a login prompt.<br />
<br />
* Use {{ic|chronos}} as the username, it should not prompt you for a password.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}}.<br />
<br />
==== Accessing the superuser shell when logged into ChromeOS ====<br />
<br />
If you have configured ChromeOS already:<br />
<br />
* Open a crosh window with {{ic|Ctrl + Alt + T}}.<br />
* Open a bash shell with the {{ic|shell}} command.<br />
* Become superuser with [[sudo]], use the command {{ic|sudo su -}} to accomplish that.<br />
<br />
=== Enabling Legacy Boot Mode ===<br />
<br />
If your ChromeOS device did not ship with Legacy Boot Mode support via SeaBIOS, or you prefer to install a custom firmware, then continue to [[#Flashing a custom firmware|Flashing a custom firmware]].<br />
<br />
This will enable the pre-installed version of SeaBIOS through the Developer Mode screen in coreboot.<br />
<br />
* Inside your superuser shell enter:<br />
# crossystem dev_boot_legacy=1<br />
* Reboot the machine.<br />
<br />
You can now start SeaBIOS by pressing {{ic|Ctrl + L}} at the white boot splash screen.<br />
<br />
{{Note|If you intend to stay using pre-installed SeaBIOS route and think you will not appreciate having to press {{ic|Ctrl + L}} every time you boot to reach SeaBIOS, then you can set coreboot to boot to SeaBIOS by default. This requires disabling the hardware firmware write protection.}}<br />
<br />
You should now have SeaBIOS enabled on your ChromeOS device, if you choose to not set it as default then you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
==== Boot to SeaBIOS by default ====<br />
<br />
To boot SeaBIOS by default, you will need to run the [https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/master/scripts/image_signing/set_gbb_flags.sh {{ic|set_gbb_flags.sh}}] script, which is part of ChromeOS. The script uses flashrom and gbb_utility to read the RO_GBB firmware region, modify the flags, and write it back to flash. The GBB flags can also be set using MrChromebox's [https://mrchromebox.tech/#fwscript Firmware Utility Script] under either ChromeOS or Arch (the latter requiring booting with specific kernel parameters to relax memory access restrictions).<br />
<br />
{{Warning|If you do not set the GBB flags, then a fully discharged or disconnected battery will reset {{ic|dev_boot_legacy}} crossystem flag to its default value, removing the ability to boot in Legacy Boot Mode. While this used to require you to recover Chrome OS and wipe your Arch Linux installation on the internal storage, the GalliumOS developers have created a set of "fixflags" recovery images, which rather than wiping internal storage, will instead simply re-set the {{ic|dev_boot_legacy}} crossystem flag. See [https://galliumos.org/fixflags galliumos.org/fixflags]}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available at the [[Custom firmware for ChromeOS devices#Firmware write protection|Custom firmware for ChromeOS devices]] page.<br />
<br />
* Switch to the [[#Accessing the superuser shell|superuser shell]].<br />
<br />
* Disable the software write protection.<br />
# flashrom --wp-disable<br />
<br />
* Check that write protection is disabled.<br />
# flashrom --wp-status<br />
<br />
* Run {{ic|set_gbb_flags.sh}} with no parameters.<br />
# /usr/share/vboot/bin/set_gbb_flags.sh<br />
<br />
* This will list all of the available flags. The ones of interest to us are:<br />
GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001<br />
GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008<br />
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080<br />
GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY 0x00000400<br />
<br />
* So, to set SeaBIOS as default, with a 1s timeout, prevent accidentally exiting Developer Mode via spacebar, and ensure Legacy Boot Mode remains enabled in the event of battery drain/disconnect, we set the flags as such:<br />
# /usr/share/vboot/bin/set_gbb_flags.sh 0x489<br />
<br />
* Enable back the software write protection.<br />
# flashrom --wp-enable<br />
<br />
{{Note|All of these steps are automated by MrChromebox's Firmware Utility Script, so if using that to install/update your RW_LEGACY firmware, easiest to just set the flags via the script as well.}}<br />
<br />
Your ChromeOS device now will boot to SeaBIOS by default, you can continue to [[#Installing Arch Linux|Installing Arch Linux]], if your device is booting correctly then you can optionally re-enable the hardware write protection.<br />
<br />
=== Flashing a custom firmware ===<br />
<br />
{{Note|The following steps explain how to flash a custom firmware from ChromeOS, for information on how to flash a custom firmware from Arch Linux visit the [[Custom firmware for ChromeOS devices]] page}}<br />
<br />
* Disable the hardware write protection.<br />
<br />
To find the location of the hardware write-protect screw/switch/jumper and how to disable it visit the ArchWiki page for your [[#Chrome OS devices|ChromeOS device]]. If there is no information about your device on the ArchWiki then turn to [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devicesDeveloper Information for ChromeOS Devices] and [http://www.coreboot.org/Chromebooks coreboot's Chromebooks page].<br />
<br />
More information about the firmware protection available at the [[Custom firmware for ChromeOS devices#Firmware write protection|Custom firmware for ChromeOS devices]] page.<br />
<br />
* Enter the command to run either MrChromebox's or John Lewis's firmware script.<br />
<br />
{{Note|The reason for not posting here is to force you to visit the site and read the instructions before proceeding.}}<br />
<br />
* After the exiting the script, be sure to copy the backed up firmware to an external storage before rebooting the system (if the script doesn't provide that option for you).<br />
<br />
You should now have a custom firmware installed on your device, cross your fingers and reboot.<br />
<br />
After flashing the firmware you can continue to [[#Installing Arch Linux|Installing Arch Linux]].<br />
<br />
=== Installing Arch Linux ===<br />
<br />
==== Preparing the installation media ====<br />
<br />
Create an [[USB flash installation media|Arch Linux Installer USB drive]].<br />
<br />
{{Note|If the USB loads but fails to boot into Arch, it may be due a bug in the syslinux the current (2017.03.01) installer uses. The 2016.11.01 version from the [[Arch Linux Archive]] will work until the issue is resolved.}}<br />
<br />
==== Booting the installation media ====<br />
<br />
* Plug the USB drive to the ChromeOS device and start SeaBIOS with {{ic|Ctrl + L}} at the white boot splash screen (if SeaBIOS is not set as default).<br />
* Press {{ic|Esc}} to get a boot menu and select the number corresponding to your USB drive.<br />
<br />
The Arch Linux installer boot menu should appear and the [[Installation guide|installation]] process can proceed as normal.<br />
<br />
{{Note|For now choose [[GRUB]] as your bootloader: you can choose MBR or GPT: [[Partitioning]]. If you choose GPT then do not forget to add a [[GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions|BIOS Boot Partition]]. Also see [[#Syslinux|Known Issues]].}}<br />
<br />
After finishing installing Arch Linux continue by following the [[#Post installation configuration|Post Installation Configuration]].<br />
<br />
== Post installation configuration ==<br />
<br />
=== Patched kernels ===<br />
{{Note|You can most likely ignore this section unless your device requires patched kernel support.}}<br />
<br />
It is recommended to use the official {{Pkg|linux}} package for most Chrome OS devices with the exception being newer devices which might need patched kernel support such as the Chromebook Pixel 2015.<br />
<br />
{{AUR|linux-samus4}} provides patches for the Chromebook Pixel 2015 to fix touchpad, touchscreen, and sound functionality which has not been merged into upstream linux yet. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
If your devices requires a patched kernel, it is advised to review the list of patches and decide if the patch list is getting decidedly small enough that you no longer require a patched kernel and instead you can use the official {{Pkg|linux}} package instead. <br />
<br />
See [[kernels]] for more information.<br />
<br />
=== Video driver ===<br />
<br />
See [[Intel graphics]].<br />
<br />
=== Touchpad and touchscreen ===<br />
<br />
See [[Touchpad Synaptics]], [[libinput]], and [[Touchscreen]].<br />
<br />
==== Touchpad and touchscreen kernel modules ====<br />
<br />
Since kernel 3.17 all the related patches merged into the upstream sources, meaning the {{Pkg|linux}} package in core supports these devices.<br />
<br />
===== What to do if your touchpad or touchscreen is not supported? =====<br />
<br />
* Review the list of patches in {{Aur|linux-chromebook}}{{Broken package link|{{aur-mirror|linux-chromebook}}}}, if a related patch for your Chromebook model exist then [[#Patched kernels|install this package]].<br />
* If there is no such patch do not worry as the developers should be able to add it by request as the Chromium OS sources includes the related changes.<br />
* You can also try to find the related commits by yourself and create a proper patch, some hints:<br />
** Dig into your Chrome OS system, look at the obvious suspects like boot log, {{ic|/proc/bus/input/devices}} and {{ic|/sys/devices}}.<br />
** The Linux kernel sources for Chromium OS are at [https://chromium.googlesource.com/chromiumos/third_party/kernel].<br />
** Each kernel source for the latest Chromium OS release has its own branch, name convention: {{ic|release-R*-*-chromeos-KERNELVER}}, where {{ic|R*-*}} is the Chromium OS release and {{ic|KERNELVER}} is the kernel version.<br />
** Review the git log of {{ic|drivers/platform}}, {{ic|drivers/i2c/busses}} and {{ic|drivers/input/touchscreen}}.<br />
* {{AUR|linux-samus4}} includes touchpad and touchscreen support for the Chromebook Pixel 2015. More information is available at [https://github.com/raphael/linux-samus its GitHub page].<br />
<br />
==== Touchpad configuration ====<br />
<br />
There are few options how to set the touchpad:<br />
<br />
* Visit the ArchWiki page for your Chromebook model (see [[#Chromebook_Models|Chromebook models]]{{Broken section link}}) for touchpad xorg.conf.d file.<br />
* Use a [[Touchpad_Synaptics#Configuration_on_the_fly|touchpad configuration tool]].<br />
<br />
==== Chromium OS input drivers ====<br />
<br />
{{Out of date|{{ic|xf86-input-cmt}} development is not active and it is probably not needed anymore in any case since [[libinput]]'s compatibility with Chrome OS devices's touchpads is fairly good.}}<br />
<br />
{{AUR|xf86-input-cmt}} offers a port of the Chromium OS input driver: [https://github.com/hugegreenbug/xf86-input-cmt xf86-input-cmt] as an alternative for the [[Synaptics|Synaptics input driver]]. It provides tweaked configuration files for most devices, and provides functionality that the [[Synaptics|Synaptics input driver]] does not such as palm rejection. Additionally, it enables functionality not enabled by default in the Chromium OS input driver such as tap-to-drag.<br />
<br />
Please note, the input driver does not work under [https://github.com/hugegreenbug/xf86-input-cmt/issues/5 some circumstances] where you have insufficient permissions to access {{ic|/dev/input/event}}<br />
This will affect you if you use [[startx]] to load a DE/WM session.<br />
If this is the case or if the driver does not load for any other cases, you should run:<br />
# usermod -a -G input $USER<br />
Where $USER is the current user wanting to use the input driver.<br />
<br />
It should also be noted that some users have reported the driver does not work in [[GDM]] but works normally after log in.<br />
If you are affected by this, you should run:<br />
# usermod -a -G input gdm<br />
<br />
After reboot, you should be able to use the touchpad normally.<br />
<br />
=== Fixing suspend ===<br />
{{Note|Lid suspend might not work directly after boot, you might need to wait a little.}}<br />
<br />
The following are instructions to fix the suspend functionality.<br />
Users of a pre-installed SeaBIOS or John Lewis' pre-built SeaBIOS you will need this fix.<br />
This procedure is not needed with Matt DeVillier's custom firmware since problematic ACPI wake devices (such as {{ic|TPAD}}) are firmware-disabled.<br />
<br />
There have been a few alternatives discussed and those may work better for some. [https://bbs.archlinux.org/viewtopic.php?pid=1364376#p1364376] [https://bbs.archlinux.org/viewtopic.php?pid=1364521#p1364521]<br />
<br />
To fix suspend, the general idea is to disable the EHCI_PCI module, which interferes with the suspend cycle. There are multiple ways to achieve this.<br />
<br />
==== With kernel parameters ====<br />
Add the following to your GRUB configuration:-<br />
<br />
{{hc|head=/etc/default/grub|<br />
output=GRUB_CMDLINE_LINUX_DEFAULT="modprobe.blacklist=ehci_pci"}}<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]]. After rebuilding your GRUB config, reboot your computer.<br />
<br />
==== With systemd ====<br />
<br />
Sometimes the synaptics touchpad, and various other parts of the laptop are used as wakeup devices causing certain movements of the laptop during suspend to end suspend. In order to disable all wakeup devices except for the laptop lid sensor, create the following {{ic|suspend-device-fix.sh}} file. <br />
<br />
{{hc|head=/usr/local/sbin/suspend-device-fix.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
awk '{if ($1 != "LID0" && $3 == "*enabled") print $1}' < /proc/acpi/wakeup | while read NAME<br />
do echo "$NAME" > /proc/acpi/wakeup<br />
done<br />
<br />
exit 0<br />
</nowiki>}}<br />
<br />
Now give the file executable permissions:<br />
# chmod +x /usr/local/sbin/suspend-device-fix.sh<br />
<br />
Create a systemd service to execute the script on every boot. <br />
{{hc|head=/etc/systemd/system/suspend-fix.service|<br />
output=[Unit]<br />
Description=Suspend Fix<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/local/sbin/suspend-device-fix.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
First [[start]] {{ic|suspend-fix.service}}. If it properly starts, then [[enable]] it to be started on bootup.<br />
<br />
Add the following line at the end of {{ic|/etc/rc.d/rc.local}} (if it does not exist, just create it) to prevent bad handling of EHCI USB:<br />
<br />
{{hc|head=/etc/rc.d/rc.local|<br />
output=<nowiki><br />
echo 1 > /sys/devices/pci0000\:00/0000\:00\:1d.0/remove<br />
</nowiki>}}<br />
<br />
Then, create the following {{ic|cros-sound-suspend.sh}} file. Only the Ath9k binding/unbinding lines are listed below; see the alternatives linked above for additional sound suspend handling if you experience issues.<br />
<br />
{{hc|head=/usr/lib/systemd/system-sleep/cros-sound-suspend.sh|<br />
output=<nowiki>#!/bin/bash<br />
<br />
case $1/$2 in<br />
pre/*)<br />
# Unbind ath9k for preventing error and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/unbind<br />
# Unbind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind<br />
;;<br />
post/*)<br />
# Bind ath9k for preventing error and and full sleep mode (wakeup by LID after hibernating) <br />
echo -n "0000:01:00.0" | tee /sys/bus/pci/drivers/ath9k/bind<br />
# bind snd_hda_intel for sound<br />
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind<br />
;;<br />
esac</nowiki>}}<br />
<br />
Make sure to make the script executable:<br />
# chmod +x /usr/lib/systemd/system-sleep/cros-sound-suspend.sh<br />
<br />
Then [[GRUB#Generate_the_main_configuration_file|rebuild your grub config]].<br />
<br />
=== Fixing audio ===<br />
<br />
==== Baytrail based models ====<br />
<br />
Audio on most baytrail models should work on {{Pkg|linux}} since fix merged into 4.19.7 [https://git.archlinux.org/linux.git/commit/?h=v4.19.7-arch1&id=f35f68c68ce48a8b70a4c3674663513825b7a1bc], to fix regression in 4.18.15, see bug report [https://lkml.org/lkml/2018/10/30/676].<br />
<br />
{{Note|If you find audio is less stable (see journal PLL mesages) using {{Pkg|linux}}, consider custom kernel with reverted fixes from custom repo [https://github.com/JSkier21/linux-max98090 linux-max98090]}}<br />
<br />
It is likely that you will also need to use {{ic|alsamixer}} from {{Pkg|alsa-utils}} to turn on "Left Speaker Mixer Left DAC" and "Right Speaker Mixer Right DAC". For more information, see [https://bugs.archlinux.org/task/48936].<br />
<br />
==== Haswell based models ====<br />
<br />
One or more of followings might help solving audio related issues, setting {{ic|snd_hda_intel}} module index reported the most useful. It is highly possible that you will not need to make any change.<br />
<br />
* Create {{ic|/etc/modprobe.d/alsa.conf}}, the option {{ic|index}} will make sure the analog output is the default (and not HDMI), the option {{ic|model}} will notify the driver our board model which will make the built-in microphone usable (you can try instead {{ic|<nowiki>model=alc283-sense-combo</nowiki>}} or {{ic|<nowiki>model=,alc283-dac-wcaps</nowiki>}}). <br />
<br />
{{hc|head=/etc/modprobe.d/alsa.conf|<br />
output=options snd_hda_intel index=1 model=,alc283-chrome}}<br />
<br />
* Use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/52d6d7d97eff76935713/raw/5b32ee11a2ebbe7a3ee0f928e49b980361a57548/.asoundrc].<br />
<br />
* If having problems with headphones (perhaps no audio playing), try {{ic|alsactl restore}} (requires {{Pkg|alsa-utils}}) in terminal. Now, ALSA should automatically switch between channels when using headphones/speakers. <br />
<br />
* To fix [[Flash]] audio with PulseAudio, use the {{ic|~/.asoundrc}} file from [https://gist.githubusercontent.com/dhead666/0eebff16cd9578c5e035/raw/d4c974fcd50565bf116c57b1884170ecb47f8bf6/.asoundrc].<br />
<br />
==== Chromebook Pixel 2015 ====<br />
<br />
{{AUR|linux-samus4}} includes a patch for Broadwell SoC sound devices. [https://github.com/raphael/linux-samus Its GitHub page] includes additional instructions for initializing the sound device.<br />
<br />
=== Hotkeys ===<br />
<br />
[https://support.google.com/chromebook/answer/1047364?hl=en The Chromebook function keys] recognized as standard F1-F10 by the kernel, it is preferable to map them accordingly to their appearance. It would also be nice to get the keys {{ic|Delete, Home, End, PgUp, PgDown}} which in Chrome OS mapped to {{ic|Alt + : BackSpace, Right, Left, Up, Down}}.<br />
<br />
==== xkeyboard configuration ====<br />
<br />
{{Pkg|xkeyboard-config}} 2.16-1 added a {{ic|chromebook}} model that enables the Chrome OS style functions for the function keys. You can, for example, set this using {{ic|localectl set-x11-keymap us chromebook}}. See the {{ic|chromebook}} definition in {{ic|/usr/share/X11/xkb/symbols/inet}} for the full mappings.<br />
<br />
==== Sxhkd configuration ====<br />
<br />
One way to set the hotkeys would be by using the [[Sxhkd]] daemon. Besides {{Pkg|sxhkd}}, this also requires [[Advanced Linux Sound Architecture|amixer]], {{Pkg|xorg-xbacklight}}, and {{Pkg|xautomation}}.<br />
<br />
* See [https://gist.github.com/dhead666/191722ec04842d8d330b] for an example configuration in {{ic|~/.config/sxhkd/sxhkdrc}}.<br />
<br />
==== Xbindkeys configuration ====<br />
<br />
Another way to configure hotkeys would be by using [[Xbindkeys]]. Besides {{Pkg|xbindkeys}} this requires [[Advanced Linux Sound Architecture|amixer]] and {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* See [https://gist.github.com/dhead666/08562a9a760b18b6e758] for an example configuration in {{ic|~/.xbindkeysrc}}.<br />
* See [https://bbs.archlinux.org/viewtopic.php?id=173418&p=3 vilefridge's xbindkeys configuration] for another example.<br />
<br />
===== Alternate xbindkeys configuration =====<br />
<br />
[http://pastie.org/9550960 Volchange] (originated in the [http://www.debianuserforums.org/viewtopic.php?f=55&t=1453#p14351 Debian User Forums])) can manipulate the volume with PulseAudio instead of using [[Advanced Linux Sound Architecture|amixer]]. Besides [http://pastie.org/9550960 Volchange] this requires {{Pkg|xorg-xbacklight}} and {{AUR|xvkbd}}.<br />
<br />
* Download the script from [http://pastie.org/9550960].<br />
* Make it executable <br />
$ chmod u+x ~/.local/bin/volchange<br />
<br />
See [https://gist.github.com/dhead666/4e23b506441ad424e26e] for a matching {{ic|~/.xbindkeysrc}}.<br />
<br />
==== Patch xkeyboard-config ====<br />
<br />
Another option is to install {{AUR|xkeyboard-config-chromebook}}, for more details visit [https://github.com/dhead666/archlinux-pkgbuilds/tree/master/xkeyboard-config-chromebook].<br />
<br />
==== Mapping in Gnome with gsettings set ====<br />
<br />
Some of the function keys can be mapped in Gnome with the advantage of HUD notifications on changes (like volume and brightness changes) which can supplement one of the mapping methods mentioned above. This [https://gist.github.com/dhead666/0b9c1cc9def939705594 linked example] maps the brightness and volume actions. Notice that {{Pkg|xdotool}} is required.<br />
<br />
=== Power key and lid switch handling ===<br />
<br />
==== Ignore using logind ====<br />
<br />
Out of the box, {{ic|systemd-logind}} will catch power key and lid switch events and handle them: it will shut down the Chromebook on a power key press, and a suspend on a lid close. However, this policy might be a bit harsh given that the power key is an ordinary key at the top right of the keyboard that might be pressed accidentally.<br />
<br />
To configure logind to ignore power key presses and lid switches, add the lines to {{ic|logind.conf}} below.<br />
<br />
{{hc|head=/etc/systemd/logind.conf|<br />
output=HandlePowerKey=ignore<br />
HandleLidSwitch=ignore}}<br />
<br />
Then [[restart]] logind for the changes to take effect.<br />
<br />
Power key and lid switch events will still be logged to journald by logind. See [[Power management#ACPI events]].<br />
<br />
==== Ignore by Gnome ====<br />
<br />
[[Install]] {{Pkg|gnome-tweaks}}, open the Tweak Tool and under Power change the Power Button Action.<br />
<br />
== Known issues ==<br />
<br />
=== Syslinux ===<br />
<br />
Follow Syslinux installation instructions carefully. Try manual installation to see where the problem comes from. If you see [[Syslinux#Missing_operating_system|Missing Operation System]] then it may be because you need to use correct bootloader binary. If syslinux does not work try another [[bootloader]] such as [[GRUB]].<br />
<br />
== See also ==<br />
<br />
* [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Developer Information for Chrome OS Devices at the Chromium Projects site]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=173418 BBS topic about the Acer C720] which include generic information on Haswell Based Chromebooks.<br />
* Re-partitioning in Chrome OS [http://chromeos-cr48.blogspot.co.uk/2012/04/chrubuntu-1204-now-with-double-bits.html], [http://goo.gl/i817v]<br />
* [http://bit.ly/NewChromebooks Brent Sullivan's the always updated list of Chrome OS devices]<br />
* [http://prodct.info/chromebooks/ Google Chromebook Comparison Chart]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Uniform_look_for_Qt_and_GTK_applications&diff=580329Uniform look for Qt and GTK applications2019-08-18T17:30:56Z<p>Phil.r.dubois: /* QGnomePlatform */ Fixed broken link</p>
<hr />
<div>[[Category:Widget toolkits]]<br />
[[Category:Eye candy]]<br />
[[es:Uniform look for Qt and GTK applications]]<br />
[[it:Uniform look for Qt and GTK applications]]<br />
[[ja:Qt と GTK アプリケーションの外観の統合]]<br />
[[ru:Uniform look for Qt and GTK applications]]<br />
[[zh-hans:Uniform look for Qt and GTK applications]]<br />
{{Related articles start}}<br />
{{Related|GTK}}<br />
{{Related|Qt}}<br />
{{Related articles end}}<br />
[[Qt]] and [[GTK]] based programs both use a different widget toolkit to render the graphical user interface. Each come with different themes, styles and icon sets by default, among other things, so the "look and feel" differ significantly. This article will help you make your Qt and GTK applications look similar for a more streamlined and integrated desktop experience.<br />
<br />
== Overview ==<br />
<br />
To get a similar look between the toolkits, you will most likely have to modify the following:<br />
* '''Theme''': The custom appearance of an application, widget set, etc. It usually consists of a style, an icon theme and a color theme.<br />
* '''Style''': The graphical layout and look of the widget set.<br />
* '''Icon Theme''': A set of global icons.<br />
* '''Color Theme''': A set of global colors that are used in conjunction with the style.<br />
<br />
You can choose various approaches:<br />
* Modify [[#Styles for both Qt and GTK|GTK and Qt styles]] separately with the tools listed below for each toolkit and aim for choosing similarly looking themes (style, colors, icons, cursors, fonts).<br />
* Use a special [[#Theme engines|theme engine]], which intermediates the modification of the other graphical toolkit to match your main toolkit.<br />
<br />
== Styles for both Qt and GTK ==<br />
There are widget style sets available for the purpose of integration, where builds are written and provided for both Qt and GTK, all major versions included. With these, you can have one look for all applications regardless of the toolkit they had been written with.<br />
<br />
{{Tip|You may want to apply user defined styles to root applications, see [[GTK#Theme not applied to root applications]] and [[Qt#Theme not applied to root applications]].}}<br />
{{Note|1=Since version 3.16, GTK 3 [https://bbs.archlinux.org/viewtopic.php?pid=1518404#p1518404 does not support] non-CSS themes, hence previous solutions such as Oxygen-Gtk are [https://bugs.kde.org/show_bug.cgi?id=340288 no longer viable] options.}}<br />
<br />
=== Breeze ===<br />
<br />
Breeze is the default Qt style of KDE Plasma. It can be installed with the {{Pkg|breeze}} package for Qt5, the {{AUR|breeze-kde4}} package for Qt4, and the {{Pkg|breeze-gtk}} package for GTK 2 and GTK 3.<br />
<br />
Once installed, you can use one of the many [[GTK#Configuration tools|GTK configuration tools]] to change the GTK theme. <br />
<br />
If running KDE Plasma, install {{pkg|kde-gtk-config}} and either run it from the command line, or go to ''System Settings > Application Style > GNOME Application Style (GTK)''. Fonts, icon themes, cursors, and widget styles set in System Settings outside of the GTK configuration module will affect Qt only; GTK settings should be set manually using the previously mentioned module.<br />
<br />
=== Adwaita ===<br />
<br />
Adwaita is the default GNOME theme. The GTK 3 version is included in the {{Pkg|gtk3}} package, while the GTK 2 version is in {{Pkg|gnome-themes-extra}}. [https://github.com/MartinBriza/adwaita-qt adwaita-qt] is a Qt port of the Adwaita theme. Unlike [[#QGtkStyle]], which mimics the GTK 2 theme, it provides a native Qt style made to look like the GTK 3 Adwaita. It can be [[install|installed]] with the {{AUR|adwaita-qt4}} and {{AUR|adwaita-qt}} packages for the Qt 4 and 5 versions, respectively.<br />
<br />
To set the Qt style as default:<br />
<br />
* For Qt4, it can be enabled with ''Qt Configuration'' ({{ic|qtconfig-qt4}}), choose ''adwaita'' under ''Appearance > GUI Style''. Alternatively, edit the {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific) file:<br />
<br />
{{hc|~/.config/Trolltech.conf|2=<br />
...<br />
[Qt]<br />
style=adwaita<br />
...<br />
}}<br />
<br />
* For Qt 5, it can be enabled by setting the following [[Environment variables#Graphical applications|environment variable]]{{Broken section link}}: {{ic|1=QT_STYLE_OVERRIDE=adwaita}}. Alternatively, use {{Pkg|qt5ct}} package. For more detailed instructions, see [[Qt#Configuration of Qt5 apps under environments other than KDE Plasma]].<br />
<br />
=== Kvantum ===<br />
<br />
Kvantum ({{Pkg|kvantum-qt5}}) is customizable SVG-based theme engine for Qt5 that comes with a variety of built-in styles, including versions of some of popular GTK themes such as Adapta, Arc, Ambiance, Materia.<br />
<br />
== Theme engines ==<br />
<br />
A ''theme engine'' can be thought of as a thin layer API which translates themes (excluding icons) between one or more toolkits. These engines add some extra code in the process and it is arguable that this kind of a solution is not as elegant and optimal as using native styles.<br />
<br />
=== QGtkStyle ===<br />
<br />
{{Note|QGtkStyle has been removed from {{Pkg|qt5-base}} 5.7.0 [https://github.com/qtproject/qtbase/commit/899a815414e95da8d9429a4a4f4d7094e49cfc55] and added to {{Pkg|qt5-styleplugins}} [https://github.com/qtproject/qtstyleplugins/commit/102da7d50231fc5723dba6e72340bef3d29471aa]}}<br />
<br />
{{Warning|Depending on GTK 2 theme, this style may cause rendering issues such as transparent fonts or inconsistent widgets.}}<br />
<br />
This Qt style uses GTK 2 to render all components to blend in with [[GNOME]] and similar GTK based environments. Beginning with Qt 4.5, this style is included in Qt. It requires {{Pkg|gtk2}} to be installed and configured.<br />
<br />
This is the default Qt4 style in Cinnamon, GNOME and Xfce, and the default Qt5 style in Cinnamon, GNOME, MATE, LXDE and Xfce. In other environments:<br />
<br />
* For Qt4, it can be enabled with ''Qt Configuration'' ({{ic|qtconfig-qt4}}), choose ''GTK'' under ''Appearance > GUI Style''. Alternatively, edit the {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific) file:<br />
<br />
{{hc|~/.config/Trolltech.conf|2=<br />
...<br />
[Qt]<br />
style=GTK+<br />
...<br />
}}<br />
<br />
* For Qt 5, it can be enabled by installing {{Pkg|qt5-styleplugins}} and setting the following [[Environment variables#Graphical environment|environment variable]]: {{ic|1=QT_QPA_PLATFORMTHEME=gtk2}}<br />
<br />
For full uniformity, make sure that the configured [[GTK#Themes|GTK theme]] supports both GTK 2 and GTK 3. If your preferred theme has inconsistent rendering after configuring Qt to use GTK2, install {{Pkg|gtk-theme-switch2}} and choose a theme.<br />
<br />
=== QGnomePlatform ===<br />
<br />
This Qt 5 platform theme applies the appearance settings of GNOME for Qt applications. It can be installed with the {{AUR|qgnomeplatform}} package or the {{AUR|qgnomeplatform-git}} package for the development version. It does not provide a Qt style itself, instead it requires a [[#Styles for both Qt and GTK|style that support both Qt and GTK]].<br />
<br />
This platform theme is enabled automatically in GNOME since version 3.20. For other systems, it can be enabled by setting the following [[Environment variables#Graphical environment|environment variable]]: {{ic|1=QT_QPA_PLATFORMTHEME=qgnomeplatform}}.<br />
<br />
== Tips and tricks ==<br />
=== KDE file dialogs for GTK applications ===<br />
<br />
'''Chromium'''<br />
<br />
At least for chromium installing {{ic|kdialog}} makes chromium used kde file dialog ( so `KGtk-wrapper` is not required )<br />
<br />
{{Out of date|KGtk-wrapper has not been updated for years, and can't be used anymore - several dependencies are missing.}}<br />
<br />
{{Warning|Some GTK applications may not be compatible with KGtk-wrapper (e.g. [[Chromium]]), sometimes the wrapper makes the application crash ([[Firefox]] or [[Thunderbird]]).}}<br />
<br />
{{AUR|kgtk}} from the [[AUR]] is a wrapper script which uses {{ic|LD_PRELOAD}} to force KDE file dialogs in GTK 2.x apps. Once installed you can run GTK 2.x applications with {{ic|kgtk-wrapper}} in two ways (using [[GIMP]] in the examples):<br />
<br />
* Calling {{ic|kgtk-wrapper}} directly and using the GTK 2.x binary as an argument:<br />
:{{bc|$ /usr/bin/kgtk-wrapper gimp}}<br />
* Modifying the KDE .desktop shortcuts files you can find at {{ic|/usr/share/applications/}} to prefix the {{ic|Exec}} statement with kgtk-wrapper.<br />
:e.g. with [[GIMP]], edit the {{ic|/usr/share/applications/gimp.desktop}} shortcut file and replace {{ic|1=Exec=gimp-2.8 %U}} by {{ic|1=Exec=kgtk-wrapper gimp-2.8 %U}}.<br />
<br />
'''Firefox'''<br />
<br />
Firefox can use kde file dialogs natively. See [[Firefox#KDE/GNOME integration]]<br />
<br />
=== Using a GTK icon theme in Qt apps ===<br />
<br />
{{Style|Duplicates [[environment variables]]}}<br />
<br />
If you are running Plasma, install {{Pkg|kde-gtk-config}} and select the icon-theme under ''System Settings > Application Style > GTK''.<br />
<br />
If you are using [[GNOME]], first check if {{Pkg|dconf-editor}} is installed.<br />
<br />
Then, run {{ic|dconf-editor}} and look under ''org > gnome > desktop > interface'' for {{ic|icon-theme}} key and change it to your preferred icon theme. <br />
<br />
If you are not using [[GNOME]], for example if you are running a minimal system with {{Pkg|i3-wm}}, first install {{Pkg|dconf-editor}}. <br />
<br />
Then, run {{ic|dconf-editor}} and look under ''org > gnome > desktop > interface'' for {{ic|icon-theme}} key and change it to your preferred icon theme. <br />
<br />
Since, you are not using [[GNOME]], you might have to set the value of {{ic|DESKTOP_SESSION}} in your profile. To do that execute the below code in a terminal and restart your system.<br />
<br />
$ echo 'export DESKTOP_SESSION=gnome' >> /etc/profile<br />
<br />
'''OR'''<br />
<br />
Set {{ic|1=export DESKTOP_SESSION=gnome}} somewhere in your {{ic|~/.xinitrc}} or, if you are using a [[Display manager]] in [[Xprofile]].<br />
<br />
{{Note| If the icon theme was not applied, you might want to check if the name that you entered of your preferred theme, was in the correct format. For example, if you want to apply the currently active icon theme to your QT applications, you can find the correct format of it's name with the command:<br />
<br />
{{bc|1=$ cat ~/.gtkrc-2.0 {{!}} grep icon-theme {{!}} cut -d= -f2}}<br />
<br />
}}<br />
<br />
=== Add Title bar and frame to GTK3 applications under KDE Plasma ===<br />
<br />
To have Gnome/GTK applications display with a KDE/Plasma title bar and frame, install {{AUR|gtk3-nocsd-git}} and restart your window manager to load the updated library path.<br />
<br />
You can also run Gtk application with the wrapper:<br />
$ gtk3-nocsd gedit<br />
<br />
=== Improve subpixel rendering of GTK apps under KDE Plasma ===<br />
<br />
See [[Font configuration#LCD filter]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Qt applications do not use QGtkStyle ===<br />
<br />
{{Out of date|GTK-Qt Engine has been unmaintained for a while.|section=For removal or needs rewrite}}<br />
<br />
Qt will not apply QGtkStyle correctly if GTK is using the [[#GTK-Qt Engine|GTK-Qt Engine]]{{Broken section link}}. Qt determines whether the GTK-Qt Engine is in use by reading the GTK configuration files listed in the environmental variable {{ic|GTK2_RC_FILES}}. If the environmental variable is not set properly, Qt assumes you are using the engine, sets QGtkStyle to use the style GTK style ''Clearlooks'', and outputs an error message:<br />
<br />
QGtkStyle cannot be used together with the GTK_Qt engine.<br />
<br />
Another error you may get after launching {{ic|qtconfig-qt4}} from a shell and selecting the GTK style is:<br />
<br />
QGtkStyle was unable to detect the current GTK theme.<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id&#61;99175&p&#61;1 this thread], you may simply have to install {{AUR|libgnomeui}} to solve this issue. This has the added benefit that you do not need to edit a file every time you change your theme via a graphical tool, like the one provided by xfce.<br />
<br />
Users of [[Openbox]] and other non-GNOME environments may encounter this problem. To solve this, first add the following to your {{ic|.xinitrc}} file:<br />
<br />
{{hc|.xinitrc|<nowiki><br />
...<br />
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"<br />
...<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Make sure to add this line before invoking the window manager.<br />
* You can add multiple paths by separating them with colons.<br />
* Make sure to use {{ic|$HOME}} instead of {{ic|~}} as it will not properly expand to the user's home directory.<br />
}}<br />
<br />
Then specify the theme you want in the {{ic|~/.gtkrc-2.0}} file using a [[GTK#Configuration_tools|dedicated application]] or manually, by adding:<br />
<br />
{{hc|.gtkrc-2.0|<nowiki><br />
...<br />
gtk-theme-name="[name of theme]"<br />
...<br />
</nowiki>}}<br />
<br />
Some tools only insert the following include directive in {{ic|~/.gtkrc-2.0}}:<br />
<br />
{{hc|.gtkrc-2.0|<br />
...<br />
include "/usr/share/themes/SomeTheme/gtk-2.0/gtkrc"<br />
...<br />
}}<br />
<br />
which apparently is not recognized by all versions of QGtkStyle. You can hotfix this problem by inserting the {{ic|gtk-theme-name}} manually in your {{ic|~/.gtkrc-2.0}} file like above.<br />
<br />
{{Note|Style-changing applications will most probably rewrite the {{ic|~/.gtkrc-2.0}} file the next time you change themes.}}<br />
<br />
If these steps do not work, install {{Pkg|gconf}} and run this command:<br />
<br />
gconftool-2 --set --type string /desktop/gnome/interface/gtk_theme [name of theme]<br />
<br />
If you further want to set the same icon and cursor theme, then you have to specify them, too.<br />
<br />
gconftool-2 --set --type string /desktop/gnome/interface/icon_theme Faenza-Dark<br />
<br />
This sets the icon theme to Faenza-Dark located in {{ic|/usr/share/icons/Faenza-Dark}}. For the cursor theme you first have to set the gconf value.<br />
<br />
gconftool-2 --set --type string /desktop/gnome/peripherals/mouse/cursor_theme Adwaita<br />
<br />
Then you will have to create the file {{ic|/usr/share/icons/default/index.theme}} with the following lines:<br />
<br />
[Icon Theme]<br />
Inherits=Adwaita<br />
<br />
=== Themes not working in GTK apps ===<br />
<br />
If the style or theme engine you set up is not showing in your GTK applications then it is likely your GTK settings files are not being loaded for some reason. You can check where your system expects to find these files by doing the following..<br />
$ export | grep gtk<br />
<br />
Usually the expected files should be {{ic|~/.gtkrc}} for GTK1 and {{ic|~/.gtkrc2.0}} or {{ic|~/.gtkrc2.0-kde}} for GTK 2.x.<br />
<br />
=== GTK apps don't use svg (breeze) icons after system upgrade ===<br />
<br />
Try to run this to fix this issue:<br />
# gdk-pixbuf-query-loaders --update-cache</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Uniform_look_for_Qt_and_GTK_applications&diff=580328Uniform look for Qt and GTK applications2019-08-18T17:30:26Z<p>Phil.r.dubois: /* QGtkStyle */ Fixed broken link</p>
<hr />
<div>[[Category:Widget toolkits]]<br />
[[Category:Eye candy]]<br />
[[es:Uniform look for Qt and GTK applications]]<br />
[[it:Uniform look for Qt and GTK applications]]<br />
[[ja:Qt と GTK アプリケーションの外観の統合]]<br />
[[ru:Uniform look for Qt and GTK applications]]<br />
[[zh-hans:Uniform look for Qt and GTK applications]]<br />
{{Related articles start}}<br />
{{Related|GTK}}<br />
{{Related|Qt}}<br />
{{Related articles end}}<br />
[[Qt]] and [[GTK]] based programs both use a different widget toolkit to render the graphical user interface. Each come with different themes, styles and icon sets by default, among other things, so the "look and feel" differ significantly. This article will help you make your Qt and GTK applications look similar for a more streamlined and integrated desktop experience.<br />
<br />
== Overview ==<br />
<br />
To get a similar look between the toolkits, you will most likely have to modify the following:<br />
* '''Theme''': The custom appearance of an application, widget set, etc. It usually consists of a style, an icon theme and a color theme.<br />
* '''Style''': The graphical layout and look of the widget set.<br />
* '''Icon Theme''': A set of global icons.<br />
* '''Color Theme''': A set of global colors that are used in conjunction with the style.<br />
<br />
You can choose various approaches:<br />
* Modify [[#Styles for both Qt and GTK|GTK and Qt styles]] separately with the tools listed below for each toolkit and aim for choosing similarly looking themes (style, colors, icons, cursors, fonts).<br />
* Use a special [[#Theme engines|theme engine]], which intermediates the modification of the other graphical toolkit to match your main toolkit.<br />
<br />
== Styles for both Qt and GTK ==<br />
There are widget style sets available for the purpose of integration, where builds are written and provided for both Qt and GTK, all major versions included. With these, you can have one look for all applications regardless of the toolkit they had been written with.<br />
<br />
{{Tip|You may want to apply user defined styles to root applications, see [[GTK#Theme not applied to root applications]] and [[Qt#Theme not applied to root applications]].}}<br />
{{Note|1=Since version 3.16, GTK 3 [https://bbs.archlinux.org/viewtopic.php?pid=1518404#p1518404 does not support] non-CSS themes, hence previous solutions such as Oxygen-Gtk are [https://bugs.kde.org/show_bug.cgi?id=340288 no longer viable] options.}}<br />
<br />
=== Breeze ===<br />
<br />
Breeze is the default Qt style of KDE Plasma. It can be installed with the {{Pkg|breeze}} package for Qt5, the {{AUR|breeze-kde4}} package for Qt4, and the {{Pkg|breeze-gtk}} package for GTK 2 and GTK 3.<br />
<br />
Once installed, you can use one of the many [[GTK#Configuration tools|GTK configuration tools]] to change the GTK theme. <br />
<br />
If running KDE Plasma, install {{pkg|kde-gtk-config}} and either run it from the command line, or go to ''System Settings > Application Style > GNOME Application Style (GTK)''. Fonts, icon themes, cursors, and widget styles set in System Settings outside of the GTK configuration module will affect Qt only; GTK settings should be set manually using the previously mentioned module.<br />
<br />
=== Adwaita ===<br />
<br />
Adwaita is the default GNOME theme. The GTK 3 version is included in the {{Pkg|gtk3}} package, while the GTK 2 version is in {{Pkg|gnome-themes-extra}}. [https://github.com/MartinBriza/adwaita-qt adwaita-qt] is a Qt port of the Adwaita theme. Unlike [[#QGtkStyle]], which mimics the GTK 2 theme, it provides a native Qt style made to look like the GTK 3 Adwaita. It can be [[install|installed]] with the {{AUR|adwaita-qt4}} and {{AUR|adwaita-qt}} packages for the Qt 4 and 5 versions, respectively.<br />
<br />
To set the Qt style as default:<br />
<br />
* For Qt4, it can be enabled with ''Qt Configuration'' ({{ic|qtconfig-qt4}}), choose ''adwaita'' under ''Appearance > GUI Style''. Alternatively, edit the {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific) file:<br />
<br />
{{hc|~/.config/Trolltech.conf|2=<br />
...<br />
[Qt]<br />
style=adwaita<br />
...<br />
}}<br />
<br />
* For Qt 5, it can be enabled by setting the following [[Environment variables#Graphical applications|environment variable]]{{Broken section link}}: {{ic|1=QT_STYLE_OVERRIDE=adwaita}}. Alternatively, use {{Pkg|qt5ct}} package. For more detailed instructions, see [[Qt#Configuration of Qt5 apps under environments other than KDE Plasma]].<br />
<br />
=== Kvantum ===<br />
<br />
Kvantum ({{Pkg|kvantum-qt5}}) is customizable SVG-based theme engine for Qt5 that comes with a variety of built-in styles, including versions of some of popular GTK themes such as Adapta, Arc, Ambiance, Materia.<br />
<br />
== Theme engines ==<br />
<br />
A ''theme engine'' can be thought of as a thin layer API which translates themes (excluding icons) between one or more toolkits. These engines add some extra code in the process and it is arguable that this kind of a solution is not as elegant and optimal as using native styles.<br />
<br />
=== QGtkStyle ===<br />
<br />
{{Note|QGtkStyle has been removed from {{Pkg|qt5-base}} 5.7.0 [https://github.com/qtproject/qtbase/commit/899a815414e95da8d9429a4a4f4d7094e49cfc55] and added to {{Pkg|qt5-styleplugins}} [https://github.com/qtproject/qtstyleplugins/commit/102da7d50231fc5723dba6e72340bef3d29471aa]}}<br />
<br />
{{Warning|Depending on GTK 2 theme, this style may cause rendering issues such as transparent fonts or inconsistent widgets.}}<br />
<br />
This Qt style uses GTK 2 to render all components to blend in with [[GNOME]] and similar GTK based environments. Beginning with Qt 4.5, this style is included in Qt. It requires {{Pkg|gtk2}} to be installed and configured.<br />
<br />
This is the default Qt4 style in Cinnamon, GNOME and Xfce, and the default Qt5 style in Cinnamon, GNOME, MATE, LXDE and Xfce. In other environments:<br />
<br />
* For Qt4, it can be enabled with ''Qt Configuration'' ({{ic|qtconfig-qt4}}), choose ''GTK'' under ''Appearance > GUI Style''. Alternatively, edit the {{ic|/etc/xdg/Trolltech.conf}} (system-wide) or {{ic|~/.config/Trolltech.conf}} (user-specific) file:<br />
<br />
{{hc|~/.config/Trolltech.conf|2=<br />
...<br />
[Qt]<br />
style=GTK+<br />
...<br />
}}<br />
<br />
* For Qt 5, it can be enabled by installing {{Pkg|qt5-styleplugins}} and setting the following [[Environment variables#Graphical environment|environment variable]]: {{ic|1=QT_QPA_PLATFORMTHEME=gtk2}}<br />
<br />
For full uniformity, make sure that the configured [[GTK#Themes|GTK theme]] supports both GTK 2 and GTK 3. If your preferred theme has inconsistent rendering after configuring Qt to use GTK2, install {{Pkg|gtk-theme-switch2}} and choose a theme.<br />
<br />
=== QGnomePlatform ===<br />
<br />
This Qt 5 platform theme applies the appearance settings of GNOME for Qt applications. It can be installed with the {{AUR|qgnomeplatform}} package or the {{AUR|qgnomeplatform-git}} package for the development version. It does not provide a Qt style itself, instead it requires a [[#Styles for both Qt and GTK|style that support both Qt and GTK]].<br />
<br />
This platform theme is enabled automatically in GNOME since version 3.20. For other systems, it can be enabled by setting the following [[Environment variables#Graphical applications|environment variable]]{{Broken section link}}: {{ic|1=QT_QPA_PLATFORMTHEME=qgnomeplatform}}.<br />
<br />
== Tips and tricks ==<br />
=== KDE file dialogs for GTK applications ===<br />
<br />
'''Chromium'''<br />
<br />
At least for chromium installing {{ic|kdialog}} makes chromium used kde file dialog ( so `KGtk-wrapper` is not required )<br />
<br />
{{Out of date|KGtk-wrapper has not been updated for years, and can't be used anymore - several dependencies are missing.}}<br />
<br />
{{Warning|Some GTK applications may not be compatible with KGtk-wrapper (e.g. [[Chromium]]), sometimes the wrapper makes the application crash ([[Firefox]] or [[Thunderbird]]).}}<br />
<br />
{{AUR|kgtk}} from the [[AUR]] is a wrapper script which uses {{ic|LD_PRELOAD}} to force KDE file dialogs in GTK 2.x apps. Once installed you can run GTK 2.x applications with {{ic|kgtk-wrapper}} in two ways (using [[GIMP]] in the examples):<br />
<br />
* Calling {{ic|kgtk-wrapper}} directly and using the GTK 2.x binary as an argument:<br />
:{{bc|$ /usr/bin/kgtk-wrapper gimp}}<br />
* Modifying the KDE .desktop shortcuts files you can find at {{ic|/usr/share/applications/}} to prefix the {{ic|Exec}} statement with kgtk-wrapper.<br />
:e.g. with [[GIMP]], edit the {{ic|/usr/share/applications/gimp.desktop}} shortcut file and replace {{ic|1=Exec=gimp-2.8 %U}} by {{ic|1=Exec=kgtk-wrapper gimp-2.8 %U}}.<br />
<br />
'''Firefox'''<br />
<br />
Firefox can use kde file dialogs natively. See [[Firefox#KDE/GNOME integration]]<br />
<br />
=== Using a GTK icon theme in Qt apps ===<br />
<br />
{{Style|Duplicates [[environment variables]]}}<br />
<br />
If you are running Plasma, install {{Pkg|kde-gtk-config}} and select the icon-theme under ''System Settings > Application Style > GTK''.<br />
<br />
If you are using [[GNOME]], first check if {{Pkg|dconf-editor}} is installed.<br />
<br />
Then, run {{ic|dconf-editor}} and look under ''org > gnome > desktop > interface'' for {{ic|icon-theme}} key and change it to your preferred icon theme. <br />
<br />
If you are not using [[GNOME]], for example if you are running a minimal system with {{Pkg|i3-wm}}, first install {{Pkg|dconf-editor}}. <br />
<br />
Then, run {{ic|dconf-editor}} and look under ''org > gnome > desktop > interface'' for {{ic|icon-theme}} key and change it to your preferred icon theme. <br />
<br />
Since, you are not using [[GNOME]], you might have to set the value of {{ic|DESKTOP_SESSION}} in your profile. To do that execute the below code in a terminal and restart your system.<br />
<br />
$ echo 'export DESKTOP_SESSION=gnome' >> /etc/profile<br />
<br />
'''OR'''<br />
<br />
Set {{ic|1=export DESKTOP_SESSION=gnome}} somewhere in your {{ic|~/.xinitrc}} or, if you are using a [[Display manager]] in [[Xprofile]].<br />
<br />
{{Note| If the icon theme was not applied, you might want to check if the name that you entered of your preferred theme, was in the correct format. For example, if you want to apply the currently active icon theme to your QT applications, you can find the correct format of it's name with the command:<br />
<br />
{{bc|1=$ cat ~/.gtkrc-2.0 {{!}} grep icon-theme {{!}} cut -d= -f2}}<br />
<br />
}}<br />
<br />
=== Add Title bar and frame to GTK3 applications under KDE Plasma ===<br />
<br />
To have Gnome/GTK applications display with a KDE/Plasma title bar and frame, install {{AUR|gtk3-nocsd-git}} and restart your window manager to load the updated library path.<br />
<br />
You can also run Gtk application with the wrapper:<br />
$ gtk3-nocsd gedit<br />
<br />
=== Improve subpixel rendering of GTK apps under KDE Plasma ===<br />
<br />
See [[Font configuration#LCD filter]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Qt applications do not use QGtkStyle ===<br />
<br />
{{Out of date|GTK-Qt Engine has been unmaintained for a while.|section=For removal or needs rewrite}}<br />
<br />
Qt will not apply QGtkStyle correctly if GTK is using the [[#GTK-Qt Engine|GTK-Qt Engine]]{{Broken section link}}. Qt determines whether the GTK-Qt Engine is in use by reading the GTK configuration files listed in the environmental variable {{ic|GTK2_RC_FILES}}. If the environmental variable is not set properly, Qt assumes you are using the engine, sets QGtkStyle to use the style GTK style ''Clearlooks'', and outputs an error message:<br />
<br />
QGtkStyle cannot be used together with the GTK_Qt engine.<br />
<br />
Another error you may get after launching {{ic|qtconfig-qt4}} from a shell and selecting the GTK style is:<br />
<br />
QGtkStyle was unable to detect the current GTK theme.<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id&#61;99175&p&#61;1 this thread], you may simply have to install {{AUR|libgnomeui}} to solve this issue. This has the added benefit that you do not need to edit a file every time you change your theme via a graphical tool, like the one provided by xfce.<br />
<br />
Users of [[Openbox]] and other non-GNOME environments may encounter this problem. To solve this, first add the following to your {{ic|.xinitrc}} file:<br />
<br />
{{hc|.xinitrc|<nowiki><br />
...<br />
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"<br />
...<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* Make sure to add this line before invoking the window manager.<br />
* You can add multiple paths by separating them with colons.<br />
* Make sure to use {{ic|$HOME}} instead of {{ic|~}} as it will not properly expand to the user's home directory.<br />
}}<br />
<br />
Then specify the theme you want in the {{ic|~/.gtkrc-2.0}} file using a [[GTK#Configuration_tools|dedicated application]] or manually, by adding:<br />
<br />
{{hc|.gtkrc-2.0|<nowiki><br />
...<br />
gtk-theme-name="[name of theme]"<br />
...<br />
</nowiki>}}<br />
<br />
Some tools only insert the following include directive in {{ic|~/.gtkrc-2.0}}:<br />
<br />
{{hc|.gtkrc-2.0|<br />
...<br />
include "/usr/share/themes/SomeTheme/gtk-2.0/gtkrc"<br />
...<br />
}}<br />
<br />
which apparently is not recognized by all versions of QGtkStyle. You can hotfix this problem by inserting the {{ic|gtk-theme-name}} manually in your {{ic|~/.gtkrc-2.0}} file like above.<br />
<br />
{{Note|Style-changing applications will most probably rewrite the {{ic|~/.gtkrc-2.0}} file the next time you change themes.}}<br />
<br />
If these steps do not work, install {{Pkg|gconf}} and run this command:<br />
<br />
gconftool-2 --set --type string /desktop/gnome/interface/gtk_theme [name of theme]<br />
<br />
If you further want to set the same icon and cursor theme, then you have to specify them, too.<br />
<br />
gconftool-2 --set --type string /desktop/gnome/interface/icon_theme Faenza-Dark<br />
<br />
This sets the icon theme to Faenza-Dark located in {{ic|/usr/share/icons/Faenza-Dark}}. For the cursor theme you first have to set the gconf value.<br />
<br />
gconftool-2 --set --type string /desktop/gnome/peripherals/mouse/cursor_theme Adwaita<br />
<br />
Then you will have to create the file {{ic|/usr/share/icons/default/index.theme}} with the following lines:<br />
<br />
[Icon Theme]<br />
Inherits=Adwaita<br />
<br />
=== Themes not working in GTK apps ===<br />
<br />
If the style or theme engine you set up is not showing in your GTK applications then it is likely your GTK settings files are not being loaded for some reason. You can check where your system expects to find these files by doing the following..<br />
$ export | grep gtk<br />
<br />
Usually the expected files should be {{ic|~/.gtkrc}} for GTK1 and {{ic|~/.gtkrc2.0}} or {{ic|~/.gtkrc2.0-kde}} for GTK 2.x.<br />
<br />
=== GTK apps don't use svg (breeze) icons after system upgrade ===<br />
<br />
Try to run this to fix this issue:<br />
# gdk-pixbuf-query-loaders --update-cache</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=580230Display Power Management Signaling2019-08-17T20:39:09Z<p>Phil.r.dubois: /* Disabling DPMS */ Grammar</p>
<hr />
<div>[[Category:X server]]<br />
[[Category:Power management]]<br />
[[de:DPMS]]<br />
[[ja:Display Power Management Signaling]]<br />
[[ru:Display Power Management Signaling]]<br />
[[zh-hans:Display Power Management Signaling]]<br />
'''[[Wikipedia:VESA Display Power Management Signaling|DPMS]]''' (Display Power Management Signaling) enables power saving behaviour of monitors when the computer is not in use. The time of inactivity before the monitor enters into a given saving power level, standby, suspend or off, can be set as described in {{man|3|DPMSSetTimeouts}}. Note that some monitors make no difference between various DPMS modes.<br />
<br />
== Setting up DPMS in X ==<br />
<br />
{{Note|As of Xorg 1.8 DPMS is auto detected and enabled if ACPI is also enabled at kernel runtime.}}<br />
Add the following to a file in {{ic|/etc/X11/xorg.conf.d/}} in the {{ic|Monitor}} section:<br />
Option "DPMS" "true"<br />
<br />
Add the following to the {{ic|ServerLayout}} section, change the times (in minutes) as necessary:<br />
Option "StandbyTime" "10"<br />
Option "SuspendTime" "20"<br />
Option "OffTime" "30"<br />
{{Note|If the {{ic|"OffTime"}} option does not work, use screen blanking instead, which will keep the monitor turned on with a black image. Alternatively, change {{ic|"blanktime"}} to {{ic|"0"}} to disable screen blanking<br />
Option "BlankTime" "30"<br />
<br />
An example file {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}} could look like this.<br />
<br />
Section "Monitor"<br />
Identifier "LVDS0"<br />
Option "DPMS" "false"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "ServerLayout0"<br />
Option "StandbyTime" "0"<br />
Option "SuspendTime" "0"<br />
Option "OffTime" "0"<br />
Option "BlankTime" "0"<br />
EndSection<br />
}}<br />
<br />
== Disabling DPMS ==<br />
<br />
{{Merge||The section above already mentions {{ic|"DPMS" "false"}}}}<br />
Since DPMS is enabled by default in many scenarios, explicit action must be taken to disable it.<br />
To completely disable DPMS, add the following to a file in {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}}:<br />
<br />
Section "Extensions"<br />
Option "DPMS" "Disable"<br />
EndSection<br />
<br />
== Modify DPMS and screensaver settings with a command ==<br />
<br />
It is possible to turn off your monitor with the ''xset'' command which is provided by the {{Pkg|xorg-xset}} package.<br />
<br />
Examples:<br />
<br />
{| class="wikitable"<br />
! Command<br />
! Description<br />
|-<br />
| xset s off<br />
| Disable screen saver blanking<br />
|-<br />
| xset s 3600 3600<br />
| Change blank time to 1 hour<br />
|-<br />
| xset -dpms<br />
| Turn off DPMS<br />
|-<br />
| xset s off -dpms<br />
| Disable DPMS and prevent screen from blanking<br />
|-<br />
| xset dpms force off<br />
| Turn off screen immediately<br />
|-<br />
| xset dpms force standby<br />
| Standby screen<br />
|-<br />
| xset dpms force suspend<br />
| Suspend screen<br />
|}<br />
<br />
To query the current settings:<br />
<br />
{{hc|$ xset q|<br />
...<br />
Screen Saver:<br />
prefer blanking: yes allow exposures: yes<br />
timeout: 600 cycle: 600<br />
DPMS (Energy Star):<br />
Standby: 600 Suspend: 600 Off: 600<br />
DPMS is Enabled<br />
Monitor is On<br />
}}<br />
<br />
See {{man|1|xset}} for all available commands.<br />
<br />
{{Note|<br />
* [[XScreenSaver]] and {{Pkg|xfce4-power-manager}} use their own DPMS settings and override ''xset'' configuration. See [[XScreenSaver#DPMS and blanking settings]] and [[Xfce#Display blanking]] for more information.<br />
* If using the command manually in a shell you may need to prefix it with {{ic|sleep 1;}} for it to work correctly, for example {{ic|sleep 1; xset dpms force off}}<br />
* {{ic|xset dpms 0 0 0}}, which sets all the DPMS timeouts to zero, could be a better way to "disable" DPMS, since the effect of {{ic|-dpms}} would be reverted when, for example, turning off the screen with {{ic|xset dpms force off}}.<br />
* If using {{ic|xset}} in [[xinitrc]] does not work, specify settings within a file in {{ic|/etc/X11/xorg.conf.d/}}. See [[#Setting up DPMS in X]] for details.<br />
}}<br />
<br />
== DPMS interaction in a Linux console with setterm ==<br />
<br />
The ''setterm'' utility issues terminal recognized escape codes to alter the terminal. Essentially it just writes/echos the terminal sequences to the current terminal device, whether that be in screen, a remote ssh terminal, console mode, serial consoles, etc. <br />
<br />
setterm Syntax: (0 disables)<br />
<br />
setterm -blank [0-60|force|poke]<br />
setterm -powersave [on|vsync|hsync|powerdown|off]<br />
setterm -powerdown [0-60]<br />
<br />
{{Note|If you haven't already read the brief DPMS article linked to below, please skim it to understand how DPMS can be used in the console the same as in X.}}<br />
<br />
=== Prevent screen from turning off ===<br />
<br />
You can run this command:<br />
$ setterm -blank 0 -powerdown 0<br />
<br />
Alternatively you can disable console blanking permanently using the following command:<br />
<br />
# echo -ne "\033[9;0]" >> /etc/issue<br />
<br />
Changing 0 (after the semicolon) to e.g. 3, will keep the screen on for 3 minutes, before entering standby mode.<br />
<br />
=== Pipe the output to a cat to see the escapes ===<br />
<br />
$ setterm -powerdown 2>&1 | exec cat -v 2>&1 | sed "s/\\^\\[/\\\\033/g"<br />
<br />
=== Pipe the escapes to any tty (with write/append perms) to modify that terminal ===<br />
<br />
$ setterm -powerdown 0 >> /dev/tty3<br />
<br />
{{Note|{{ic|>>}} is used instead of {{ic|>}}. For permission issues using ''sudo'' in a script or something, you can use the '''tee''' program to append the output of setterm to the tty device, which tty's let appending sometimes but not writing.}}<br />
<br />
==== Bash loop to set ttys 0-256 ====<br />
<br />
$ for i in {0..256}; do setterm -powerdown 0 >> /dev/tty$i; done; unset i;<br />
<br />
== See also ==<br />
<br />
* [https://web.archive.org/web/20180129095655/http://webpages.charter.net/dperr/dpms.htm PC Monitor DPMS specification explanation]<br />
* [http://ptspts.blogspot.be/2009/10/screen-blanking-dpms-screen-saver.html DPMS control in X]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Openbox&diff=566966Openbox2019-02-20T22:18:46Z<p>Phil.r.dubois: /* Themes */ Undo my last edit: I realized the two packages offer different settings as well.</p>
<hr />
<div>[[Category:Stacking WMs]]<br />
[[cs:Openbox]]<br />
[[de:Openbox]]<br />
[[el:Openbox]]<br />
[[es:Openbox]]<br />
[[fr:Openbox]]<br />
[[it:Openbox]]<br />
[[ja:Openbox]]<br />
[[ko:Openbox]]<br />
[[lt:Openbox]]<br />
[[nl:Openbox]]<br />
[[pl:Openbox]]<br />
[[ru:Openbox]]<br />
[[sk:Openbox]]<br />
[[sr:Openbox]]<br />
[[zh-hans:Openbox]]<br />
[[zh-hant:Openbox]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Display manager}}<br />
{{Related|File manager functionality}}<br />
{{Related|Xdg-menu}}<br />
{{Related|Oblogout}}<br />
{{Related articles end}}<br />
<br />
[http://openbox.org/wiki/Main_Page Openbox] is a lightweight, powerful, and highly configurable ''stacking'' [[window manager]] with extensive standards support. It may be built upon and run independently as the basis of a unique [[desktop environment]], or within other integrated desktop environments such as [[KDE]] and [[Xfce]], as an alternative to the window managers they provide. The [[LXDE]] desktop environment is itself built around Openbox.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openbox}} package.<br />
<br />
== Starting ==<br />
<br />
=== Standalone ===<br />
<br />
Run {{ic|openbox}} or {{ic|openbox-session}} with [[xinit]]. Note that only {{ic|openbox-session}} provides [[#Autostart]].<br />
<br />
{{Note|After executing openbox-session, there is only a blank grey screen. Try to move your mouse and '''right click''' to get an openbox menu to make sure that it is actually working.}}<br />
<br />
=== Other desktop environments ===<br />
<br />
{{Note|<br />
* When replacing the native window manager of a [[desktop environment]] with Openbox, keep in mind that Openbox does not provide any compositing effects (such as transparency). See [[#Compositing effects]].<br />
* Openbox does work with GNOME applications (but see [[GTK+#Client-side decorations]]). [http://comments.gmane.org/gmane.comp.window-managers.openbox/6595]}}<br />
<br />
See [[Desktop environment#Use a different window manager]].<br />
<br />
== Configuration==<br />
<br />
{{Note|Local configuration files will always override global equivalents.}}<br />
<br />
Four key files form the basis of the [http://openbox.org/wiki/Configuration openbox configuration], each serving a unique role. They are: {{ic|rc.xml}}, {{ic|menu.xml}}, {{ic|autostart}}, and {{ic|environment}}. Although these files are discussed in more detail below, to start configuring Openbox, it will first be necessary to create a '''local''' Openbox profile (i.e for your specific user account) based on them. This can be done by copying them from the '''global''' {{ic|/etc/xdg/openbox}} profile (applicable to any and all users) as a template:<br />
<br />
$ cp -R /etc/xdg/openbox ~/.config/<br />
<br />
=== rc.xml ===<br />
<br />
{{Tip|Custom keyboard shortcuts (keybindings) must be added to the {{ic|<keyboard>}} section of this file, and underneath the {{ic|<nowiki><!-- Keybindings for running aplications --></nowiki>}} heading.}}<br />
<br />
{{ic|~/.config/openbox/rc.xml}} is the main configuration file, responsible for determining the behaviour and settings of the overall session, including:<br />
<br />
* Keyboard shortcuts (e.g. starting applications; controlling the volume)<br />
* Theming<br />
* Desktop and Virtual desktop settings, and<br />
* Application Window settings<br />
<br />
This file is also pre-configured, meaning that it will only be necessary to amend existing content in order to customise behaviour to suit personal preference.<br />
<br />
{{Note|Per-application settings pertaining to fixed placement of applications per monitor will only work if the x & y position have also been defined.}}<br />
<br />
=== menu.xml ===<br />
<br />
{{ic|~/.config/openbox/menu.xml}} defines the type and behaviour of the desktop menu, accessable by right-clicking the background. Although the default provided is a '''static menu''' (meaning that it will not automatically update when new applications are installed), it is possible to employ the use of '''dynamic menus''' that will automatically update as well. <br />
<br />
The available options are discussed extensively below in the [[#Menus]] section.<br />
<br />
=== Autostart ===<br />
<br />
{{ic|openbox-session}} provides two autostart mechanisms: [[XDG Autostart]] (which only works if {{Pkg|python2-xdg}} is installed) and [http://openbox.org/wiki/Help:Autostart Openbox's own autostart mechanism].<br />
<br />
Openbox's own autostart mechanism:<br />
<br />
* sources {{ic|/etc/xdg/openbox/environment}}<br />
* sources {{ic|~/.config/openbox/environment}}<br />
* runs {{ic|/etc/xdg/openbox/autostart}}<br />
* runs {{ic|~/.config/openbox/autostart}}<br />
<br />
Issues regarding commands in {{ic|~/.config/openbox/autostart}} being executed out of order (or skipped altogether) are often resolved by the addition of small delays. For instance:<br />
<br />
xset -b<br />
(sleep 3s && nm-applet) &<br />
(sleep 3s && conky) &<br />
<br />
=== environment ===<br />
<br />
{{ic|~/.config/openbox/environment}} can be used to export and set relevant environmental variables such as to:<br />
<br />
* Define new pathways (e.g. execute commands that would otherwise require the entire pathway to be listed with them)<br />
* Change language settings, and<br />
* Define other variables to be used (e.g. the fix for GTK theming could be listed here)<br />
<br />
=== Themes ===<br />
<br />
Install {{Pkg|obconf}} and/or {{Pkg|lxappearance-obconf}} for a GUI to configure visual settings and theming.<br />
<br />
A good selection of themes are available in the {{Pkg|openbox-themes}} package or the [[AUR]]. Some [[GTK+#Themes]] come with an Openbox theme as well. Both Openbox-specific and Openbox-compatible themes will be installed to the {{ic|/usr/share/themes}} directory and will also be immediately available for selection.<br />
<br />
[https://www.box-look.org/browse/ord/latest/ box-look.org] is an excellent and well-established source of themes. [http://www.deviantart.com/ deviantART.com] is another excellent resource. Many more can be found online.<br />
<br />
==== Edit or create ====<br />
<br />
{{Tip|It's better to copy a theme to your home directory than to edit those found in {{ic|/usr/share/themes/}}. This will retain the original should anything go wrong and ensure that your changes are not overwritten on update.}}<br />
<br />
The process of creating new or modifying existing themes is covered extensively at the official [http://openbox.org/wiki/Help:Themes openbox.org] website. {{AUR|obtheme}} is a user-friendly GUI for doing so.<br />
<br />
=== GUI configuration ===<br />
<br />
Several GUI applications are available to quickly and easily configure your Openbox desktop.<br />
<br />
* {{App|ObConf|A GTK2 based configuration tool for the Openbox window manager.|http://openbox.org/wiki/ObConf:About|{{Pkg|obconf}}}}<br />
* {{App|LXAppearance ObConf|Plugin for LXAppearance to configure Openbox. Note that not all options to configure Openbox are available in this plugin, so you might want to install obconf anyway.|http://lxde.org|{{Pkg|lxappearance-obconf}}}}<br />
* {{App|LXInput|LXDE keyboard and mouse configuration|http://lxde.org|{{Pkg|lxinput}}}}<br />
* {{App|LXRandR|LXDE monitor configuration.|http://wiki.lxde.org/en/LXRandR|{{Pkg|lxrandr}}}}<br />
* {{App|obkey|Configure Openbox keyboard shortcuts|https://code.google.com/p/obkey/|{{AUR|obkey}}}} <br />
* {{App|ob-autostart|A simple autostart application for Openbox.|http://pastebin.com/012YgXTk|{{AUR|ob-autostart}}}} <br />
* {{App|obapps|Graphical tool for configuring application settings in Openbox.|https://sourceforge.net/projects/obapps/|{{AUR|obapps}}}} <br />
<br />
Programs and applications relating to the configuration of Openbox's desktop menu are discussed in the [[#Menus|Menus]] section.<br />
<br />
== Openbox reconfiguration ==<br />
<br />
{{Tip|where not already present, it would be worthwhile adding this command to a menu and/or as a keybind for convenience.}}<br />
<br />
Openbox will not always automatically reflect any changes made to its configuration files within a session. As a consequence, it will be necessary to manually reload those files after they have been edited. To do so, enter the following command:<br />
<br />
$ openbox --reconfigure<br />
<br />
Where intending to add this command as a keybind to {{ic|~/.config/openbox/rc.xml}}, it will only be necessary to list the command as {{ic|reconfigure}}. An example has been provided below, using the {{ic|Super}}+{{ic|F11}} keybind:<br />
<br />
<keybind key="W-F11"><br />
<action name="Reconfigure"/><br />
</keybind><br />
<br />
== Keybinds ==<br />
<br />
All keybinds must be added to the {{ic|~/.config/openbox/rc.xml}} file, and below the {{ic|<nowiki><!-- Keybindings for running aplications --></nowiki>}} heading. Although a brief overview has been provided here, a more in-depth explanation of keybindings can be found at [http://openbox.org/wiki/Help:Bindings openbox.org]. <br />
<br />
Keybinds can be added to the configuration file using the following syntax:<br />
<br />
<keybind key="'''my-key-combination'''"><br />
<action name="'''my-action'''"><br />
'''...'''<br />
</action><br />
</keybind><br />
<br />
The action name for running an external command is ''Execute''. Use the following syntax to define an external command to execute:<br />
<br />
<action name="Execute"><br />
<command>'''my-command'''</command><br />
</action><br />
<br />
See [http://openbox.org/wiki/Help:Actions the Openbox wiki] for a list of all available actions.<br />
<br />
{{Tip|The {{AUR|obkey}} utility provides a graphical interface for configuring key bindings. Before using ''obkey'', you should use ''obconf'' to create {{ic|~/.config/openbox/rc.xml}}.}}<br />
<br />
While the use of standard alpha-numeric keys for keybindings is self-explanatory, special names are assigned to other types of keys, such as {{ic|modifiers}}, {{ic|multimedia}} and {{ic|navigation}}.<br />
<br />
=== Modifiers ===<br />
<br />
{{ic|Modifier}} keys play an important role in keybindings (e.g. holding down the {{ic|shift}} or {{ic|CTRL / control}} key in combination with another key to undertake an action). Using modifiers helps to prevent conflicting keybinds, whereby two or more actions are linked to the same key or combination of keys. The syntax to use a modifier with another key is:<br />
<br />
"<modifier>-<key>"<br />
<br />
The modifier codes are as follows:<br />
<br />
* {{ic|S}}: Shift<br />
* {{ic|C}}: Control / CTRL<br />
* {{ic|A}}: Alt<br />
* {{ic|W}}: Super / Windows<br />
* {{ic|M}}: Meta<br />
* {{ic|H}}: Hyper (If it is bound to something)<br />
<br />
=== Multimedia keys ===<br />
<br />
Where available, it is possible to set the appropriate {{ic|multimedia}} keys to perform their intended functions, such as to control the volume and/or the screen brightness. These will usually be integrated into the {{ic|function}} keys, and are identified by their appropriate symbols. See [[Extra keyboard keys]] for details.<br />
<br />
The volume and brightness multimedia codes are as follows (note that commands will still have to be assigned to them to actually function):<br />
<br />
* {{ic|XF86AudioRaiseVolume}}: Increase volume<br />
* {{ic|XF86AudioLowerVolume}}: Decrease volume<br />
* {{ic|XF86AudioMute}}: Mute / unmute volume<br />
* {{ic|XF86MonBrightnessUp}}: Increase screen brightness<br />
* {{ic|XF86MonBrightnessDown}}: Decrease screen brightness<br />
<br />
For a full list of XF86 multimedia keys, see the [http://wiki.linuxquestions.org/wiki/XF86_keyboard_symbols LinuxQuestions wiki].<br />
<br />
==== Volume control ====<br />
<br />
What commands should be used for controlling the volume will depend on whether [[ALSA]], [[PulseAudio]], or [[OSS]] is used for sound.<br />
<br />
*ALSA: see [[Advanced Linux Sound Architecture#Keyboard volume control]].<br />
*PulseAudio: see [[PulseAudio#Keyboard volume control]]<br />
*OSS: see [[OSS#Using multimedia keys with OSS]].<br />
<br />
=== Navigation keys ===<br />
<br />
These are the directional / arrow keys, usually used to move the cursor up, down, left, or right. The (self-explanatory) navigation codes are as follows:<br />
<br />
* {{ic|Up}}: Up<br />
* {{ic|Down}}: Down<br />
* {{ic|Left}}: Left<br />
* {{ic|Right}}: Right<br />
<br />
== Menus ==<br />
<br />
It is possible to employ three types of menu in Openbox: {{ic|static}}, {{ic|pipes}} (dynamic), and {{ic|generators}} (static or dynamic). They may also be used alone or in any combination.<br />
<br />
=== Static ===<br />
<br />
As the name would suggest, this default type of menu does not change in any way, and may be manually edited and/or (re)generated automatically through the use on an appropriate software package.<br />
<br />
Fast and efficient, while this type of menu can be used to select applications, it can also be useful to access specific functions and/or perform specific tasks (e.g. desktop configuration), leaving the access of applications to another process (e.g. the {{Pkg|synapse}} or {{Pkg|xfce4-appfinder}} applications).<br />
<br />
The {{ic|~/.config/openbox/menu.xml}} file will be the sole source of static desktop menu content.<br />
<br />
==== menumaker ====<br />
<br />
{{Pkg|menumaker}} automatically generates {{ic|xml}} menus for several window managers, including Openbox, [[Fluxbox]], [[IceWM]] and [[Xfce]]. It will search for all installed executable programs and consequently create a menu file for them. It is also possible to configure MenuMaker to exclude certain application types (e.g. relating to [[GNOME]] or [[KDE]]), if desired.<br />
<br />
Once installed and executed, it will automatically generate a new {{ic|~/.config/openbox/menu.xml}} file. To avoid overwriting an existing file, enter:<br />
<br />
$ mmaker -v OpenBox3<br />
<br />
Otherwise, to overwrite an existing file, add the {{ic|force}} argument ({{ic|f}}):<br />
<br />
$ mmaker -vf OpenBox3<br />
<br />
Once a new {{ic|~/.config/openbox/menu.xml}} file has been generated it may then be manually edited, or configured using a GUI menu editor, such as {{Pkg|obmenu}}.<br />
<br />
==== obmenu ====<br />
<br />
{{Warning|{{ic|obm-xdg}} - a pipe menu to generate a list of [[GTK+]] and [[GNOME]] applications - is also provided with obmenu. However, it has long-running bugs whereby it may produce an invalid output, or even not function at all. Consequently it has been omitted from discussion.}}<br />
<br />
{{Pkg|obmenu}} is a "user-friendly" GUI application to edit {{ic|~/.config/openbox/menu.xml}}, without the need to code in {{ic|xml}}.<br />
<br />
==== xdg-menu ====<br />
<br />
{{Pkg|archlinux-xdg-menu}} will automatically generate a menu based on {{ic|xdg}} files contained within the {{ic|/etc/xdg/}} directory for numerous Window Managers, including Openbox. Review the [[Xdg-menu#OpenBox]] article for further information.<br />
<br />
==== logout menu options ====<br />
<br />
{{Tip|The commands provided can also be attached to [[#Keybinds|keybinds]].}}<br />
<br />
The {{ic|~/.config/openbox/menu.xml}} file can be edited in order to provide a sub-menu with the same options as provided by [[#oblogout|oblogout]]. The sample script below will provide all of these options, with the exception of the ability to lock the screen:<br />
<br />
<menu id="exit-menu" label="Exit"><br />
<item label="Log Out"><br />
<action name="Execute"><br />
<command>openbox --exit</command><br />
</action><br />
</item><br />
<item label="Shutdown"><br />
<action name="Execute"><br />
<command>systemctl poweroff</command><br />
</action><br />
</item><br />
<item label="Restart"><br />
<action name="Execute"><br />
<command>systemctl reboot</command><br />
</action><br />
</item><br />
<item label="Suspend"><br />
<action name="Execute"><br />
<command>systemctl suspend</command><br />
</action><br />
</item><br />
<item label="Hibernate"><br />
<action name="Execute"><br />
<command>systemctl hibernate</command><br />
</action><br />
</item><br />
</menu><br />
<br />
Once the entries have been composed, add the following line to present the sub-menu where desired within the main desktop menu (usually as the last entry):<br />
<br />
<menu id="exit-menu"/><br />
<br />
=== Pipes ===<br />
<br />
{{Tip|It is entirely feasible for a static menu to contain one or more pipe sub-menus. The functionality of some pipe menus may also rely on the installation of relevant software packages.}}<br />
<br />
This type of menu is in essence a script that provides dynamic, refreshed lists on-the-fly as and when run. These lists may be used for multiple purposes, including to list applications, to provide information, and to provide control functions. Pre-configured pipe menus can be installed, although not from the [[official repositories]]. More experienced users can also modify and/or create their own custom scripts. Again, {{ic|~/.config/openbox/menu.xml}} may and commonly will contain several pipe menus.<br />
<br />
==== Examples ====<br />
<br />
* {{AUR|openbox-xdgmenu}}: fast xdg-menu converter to xml-pipe-menu<br />
* {{AUR|obfilebrowser}}: Application and file browser<br />
* {{AUR|obdevicemenu}}: Management of removable media with [[Udisks]]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1345031 wifi pipe menu]: Wireless networking using [[Netctl]]<br />
<br />
[http://openbox.org/wiki/Openbox:Pipemenus Openbox.org] also provides a further list of pipe menus.<br />
<br />
=== Generators ===<br />
<br />
This type of menu is akin to those provided by the taskbars of desktop environments such as [[Xfce]] or [[LXDE]]. Automatically updating on-the-fly, this type of menu can be powerful and very convenient. It may also be possible to add custom categories and menu entries; read the documentation for your intended dynamic menu to determine if and how this can be done.<br />
<br />
A menu generator will have to be executed from the {{ic|~/.config/openbox/menu.xml}} file.<br />
<br />
==== obmenu-generator ====<br />
<br />
{{Tip|icons can still be disabled in {{AUR|obmenu-generator}}, even where enabled in {{ic|~/.config/openbox/rc.xml}}.}}<br />
<br />
{{AUR|obmenu-generator}} is highly recommended despite being an unofficial package. With the ability to be used as a static or dynamic menu, it is highly configurable, powerful, and versatile. Menu categories and individual entries may also be easily hidden, customised, and/or added with ease. The [http://trizenx.blogspot.co.uk/2012/02/obmenu-generator.html official homepage] provides further information and screenshots.<br />
<br />
Below is an example of how obmenu-generator would be dynamically executed without icons in {{ic|~/.config/openbox/menu.xml}}:<br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<openbox_menu><br />
<menu id="root-menu" label="OpenBox 3" execute="/usr/bin/obmenu-generator"><br />
</menu><br />
</openbox_menu><br />
<br />
To automatically iconify entries, the {{ic|-i}} option would be added:<br />
<br />
<menu id="root-menu" label="OpenBox 3" execute="/usr/bin/obmenu-generator -i"><br />
<br />
==== openbox-menu ====<br />
<br />
{{Tip|If this menu produces an error, it may be solved by enabling icons in {{ic|~/.config/openbox/rc.xml}}.}}<br />
<br />
{{AUR|openbox-menu}} uses the [[LXDE]] [http://sourceforge.net/projects/lxde/files/menu-cache/ menu-cache] to create dynamic menus. The [http://fabrice.thiroux.free.fr/openbox-menu_en.html official homepage] provides further information and screenshots.<br />
<br />
=== Menu icons ===<br />
<br />
To show icons next to menu entries, it will be necessary to ensure they are enabled in the {{ic|<menu>}} section of the {{ic|~/.config/openbox/rc.xml}} file:<br />
<br />
<applicationIcons>yes</applicationIcons><br />
<br />
Where using a static menu, it will then be necessary to edit the {{ic|~/.config/openbox/menu.xml}} file to provide both the {{ic|icon <nowiki>=</nowiki>}} command, along with the full path and icon name for each entry. An example of the syntax used to provide an icon for a category is:<br />
<br />
<menu id="apps-menu" label="[label name]" icon="[pathway to icon]/[icon name]"><br />
<br />
=== Desktop menu as a panel menu ===<br />
<br />
{{Tip|XDoTool can simulate any keybind for any action, and as such, it may therefore be used for many other purposes...}}<br />
<br />
[[xdotool]] is a package that can issue commands to simulate key presses / keybinds, meaning that it is possible to use it to invoke keybind-related actions without having to actually press their assigned keys. As this includes the ability to invoke an assigned keybind for the Openbox desktop menu, it is therefore possible to use XDoTool to turn the Openbox desktop menu into a panel menu. Especially where the desktop menu is heavily customised and feature-rich, this may prove very useful to:<br />
<br />
* Replace an existing panel menu<br />
* Implement a panel menu where otherwise not provided or possible (e.g. for [[Tint2]])<br />
* Compensate where losing access to the desktop menu due to the use of an application like {{pkg|xfdesktop}} to manage the [[#Desktop icons and wallpapers|desktop]].<br />
<br />
Once XDoTool has been installed - if not already present - it will be necessary to create a keybind to access the root menu in {{ic|~/.config/openbox/rc.xml}}, and again below the {{ic|<nowiki><</nowiki>!-- Keybindings for running aplications --<nowiki>></nowiki>}} heading. For example, the following code will bring up the menu by pressing {{ic|CTRL}} + {{ic|m}}:<br />
<br />
<keybind key="C-m"><br />
<action name="ShowMenu"><br />
<menu>root-menu</menu><br />
</action><br />
</keybind><br />
<br />
Openbox must then be [[#Openbox reconfiguration|reconfigured]]. In this instance, XDoTool will be used to simulate the {{ic|CTRL}} + {{ic|m}} keypress to access the desktop menu with the following command (note the use of {{ic|+}} in place of {{ic|-}}):<br />
<br />
xdotool key control+m<br />
<br />
How this command may be used as a panel launcher / icon is largely dependent on the features of panel used. While some panels will allow the above command to be executed directly in the process of creating a new launcher, others may require the use of an executable script. As an example, a custom executable script called {{ic|obpanelmenu.sh}} will be created in the {{ic|~/.config}} folder:<br />
<br />
$ ''text editor'' ~/.config/obpanelmenu.sh<br />
<br />
Once the empty file has been opened, the appropriate XDoTool command must be added to the empty file (i.e. to simulate the {{ic|CTRL}} + {{ic|m}} keypress for this example):<br />
<br />
xdotool key control+m<br />
<br />
After the file has been saved and closed, it may then be made into an executable script with the following command:<br />
<br />
$ chmod +x ~/.config/obpanelmenu.sh<br />
<br />
Executing it will bring up the Openbox desktop menu. Consequently, where using a panel that supports drag-and-drop functionality to add new launchers, simply drag the executable script onto it before changing the icon to suit personal taste.<br />
<br />
=== XDG compliant menu ===<br />
<br />
A xdg compliant menu is based on the freedesktop.org standard. The menu is defined in menu-files which reside in /etc/xdg/menus. New applications will occur automatically in the menu.<br />
<br />
==== Examples ====<br />
<br />
* [https://github.com/mlde/californium californium]: xdg menu based on the LXQt main menu and easily themable<br />
<br />
== Tips and tricks ==<br />
<br />
=== Cursor and icon themes ===<br />
<br />
See [[Cursor themes]] and [[Icons]] for details.<br />
<br />
=== Desktop icons and wallpapers ===<br />
<br />
Openbox does not natively support the use of desktop icons or wallpapers.<br />
<br />
See [[PCManFM#Desktop management|PCManFM]], [[SpaceFM#Desktop management|SpaceFM]] and [[Idesk]].<br />
<br />
{{note|You may have to edit {{ic|~/.conkyrc}} and set {{ic|own_window_type}} to {{ic|normal}}.}}<br />
<br />
See [[List of applications#Wallpaper setters]].<br />
<br />
=== Compositing effects ===<br />
<br />
Openbox does not provide native support for [[Wikipedia:Compositing window manager|compositing]], and thus requires an external compositor for this purpose.<br />
<br />
Although compositing is not a necessary component, it may specifically avoid issues such as screen distortion with [[#oblogout|oblogout]], and visual glitches with terminal window transparency. See [[Xorg#Composite]] for common choices.<br />
<br />
=== oblogout ===<br />
<br />
See the [[Oblogout]] article for an overview on how to use this useful, graphical logout script.<br />
<br />
=== Openbox for multihead users ===<br />
<br />
While Openbox provides better than average multihead support on its own, {{AUR|openbox-multihead-git}} provides a development branch called '''Openbox Multihead''' that gives multihead users per-monitor desktops. This model is not commonly found in floating window managers, but exists mainly in tiling window managers. It is explained well on the [http://xmonad.org/tour.html#workspace Xmonad web site]. Also, please see [https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD README.MULTIHEAD] for a more comprehensive description of the new features and configuration options found in Openbox Multihead.<br />
<br />
Openbox Multihead will function like normal Openbox when only a single head is available.<br />
<br />
A downside to using Openbox Multihead is that it breaks the EWMH assumption that one and only one desktop is visible at any time. Thus, existing pagers will not work well with it. To remedy this, you can install {{AUR|pager-multihead-git}}{{Broken package link|{{aur-mirror|pager-multihead-git}}}} alongside Openbox Multihead. It will work without Openbox Multihead if only one monitor is active.<br />
<br />
=== Launch a complex command with hotkey ===<br />
<br />
If you need to execute a complex command, use shell functionality.<br />
<br />
Special character replacement are as follows:<br />
<br />
* {{ic|&}}: &amp;amp;<br />
* {{ic|<}}: &amp;lt;<br />
* {{ic|>}}: &amp;gt;<br />
<br />
This example will turn off display immediately and lock screen with {{Pkg|slock}}. It was taken from [https://bbs.archlinux.org/viewtopic.php?pid=903057 this thread].<br />
<keybind key="W-l"><br />
<action name="Execute"><br />
<command>sh -c 'slock &amp;amp; (sleep .5 &amp;amp;&amp;amp; xset dpms force off)'</command><br />
</action><br />
</keybind><br />
<br />
Sometimes one need to specify environment variable for application:<br />
<keybind key="A-F7"><br />
<action name="Execute"><br />
<command>sh -c "LC_ALL=C obconf"</command><br />
</action><br />
</keybind><br />
<br />
Another example will launch application preserving all stdout and stderr output to file:<br />
<keybind key="A-f"><br />
<action name="Execute"><br />
<command>sh -c sh -c "exec gimp &amp;gt;/tmp/gimp.out 2&amp;gt;&amp;amp;1"</command><br />
</action><br />
</keybind><br />
<br />
=== Switch desktops using the mouse ===<br />
<br />
It is possible to switch desktop by moving the mouse cursor to the edges of the screen. First install {{Pkg|xdotool}} and add the following two lines to your {{ic|~/.xinitrc}}:<br />
<br />
xdotool behave_screen_edge --delay 500 left set_desktop --relative -- -1 &<br />
xdotool behave_screen_edge --delay 500 right set_desktop --relative -- +1 &<br />
<br />
=== Set default applications / file associations ===<br />
<br />
See the [[Default applications]] article.<br />
<br />
=== Ad-hoc window transparency ===<br />
<br />
{{Warning|This may not work where other actions are defined within the action group.}}<br />
The program {{Pkg|transset-df}} can enable window transparency on-the-fly.<br />
<br />
For example, using the following code in the {{ic|<mouse>}} section of the {{ic|~/.config/openbox/rc.xml}} file will enable control of application window transparency by hovering the mouse-pointer over the title bar and scrolling with the middle button:<br />
<br />
<context name="Titlebar"><br />
...<br />
<mousebind button="Up" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --inc </execute><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --dec </execute><br />
</action><br />
</mousebind><br />
...<br />
</context><br />
<br />
=== Using obxprop for faster configuration ===<br />
<br />
The {{Pkg|openbox}} package provides a {{ic|obxprop}} binary that can parse relevant values for applications settings in {{ic|rc.xml}}. Officially {{ic|<nowiki>obxprop | grep "^_OB_APP"</nowiki>}} is recommended for this task. Start the process by running the command shown, then click a window to see its properties in the terminal.<br />
<br />
=== Xprop values for applications ===<br />
<br />
{{Pkg|xorg-xprop}} can be used to relay property values for selected applications. Where frequently using per-application settings, the following [[Bash#Aliases|Bash Alias]] may be useful:<br />
dy:<br />
<br />
alias xp='xprop | grep "WM_WINDOW_ROLE\|WM_CLASS" && echo "WM_CLASS(STRING) = \"NAME\", \"CLASS\""'<br />
<br />
To use Xorg-XProp, run using the alias given {{ic|xp}}, and click on the active program desired to define with per-application settins. The results displayed will only be the information that Openbox itself requires, namely the {{ic|WM_WINDOW_ROLE}} and {{ic|WM_CLASS}} (name and class) values:<br />
<br />
WM_WINDOW_ROLE(STRING) = "roster"<br />
WM_CLASS(STRING) = "gajim.py", "Gajim.py"<br />
WM_CLASS(STRING) = "NAME", "CLASS"<br />
<br />
=== Switching between keyboard layouts ===<br />
<br />
See the article section [[Keyboard configuration in Xorg#Switching between keyboard layouts|switching between keyboard layouts]] for instructions.<br />
<br />
=== Set grid layout for virtual desktops ===<br />
<br />
Install {{AUR|obsetlayout}}. To set a 2x2 grid for example:<br />
<br />
obsetlayout 0 2 2 0<br />
<br />
Run it without arguments to know what the arguments mean.<br />
<br />
=== Enable Hot Corners ===<br />
<br />
[https://github.com/mlde/lead lead] provides hot corners for openbox and other lightweight window managers. Start the application with a entry in the autostart-file:<br />
<br />
mlde.lead &<br />
<br />
Commands can be edited in the configuration file {{ic|~/.config/mlde/lead.conf}}:<br />
<br />
[eDP1]<br />
bottom=<br />
bottomLeft=chromium<br />
bottomRight=thunar<br />
left=<br />
right=<br />
top=<br />
topLeft=mlde.californium toggle<br />
topRight=skippy-xd<br />
<br />
=== Window snapping ===<br />
<br />
Many desktop environments and window managers support ''window snapping'' (e.g. Windows 7 Aero snap), whereby they will automatically snap into place when moved to the edge of the screen. This effect can also be simulated in Openbox through the use of [[#Keybinds|keybinds]] on focused windows. <br />
<br />
As illustrated in the example below, percentages must be used to determine window sizes (see [http://openbox.org/wiki/Help:Actions openbox.org] for further information). In this instance, The {{ic|super}} key is used in conjunction with the {{ic|navigation}} keys:<br />
<br />
<keybind key="W-Left"><br />
<action name="UnmaximizeFull"/><br />
<action name="MaximizeVert"/><br />
<action name="MoveResizeTo"><br />
<width>50%</width><br />
</action><br />
<action name="MoveToEdge"><direction>west</direction></action><br />
</keybind><br />
<keybind key="W-Right"><br />
<action name="UnmaximizeFull"/><br />
<action name="MaximizeVert"/><br />
<action name="MoveResizeTo"><br />
<width>50%</width><br />
</action><br />
<action name="MoveToEdge"><direction>east</direction></action><br />
</keybind><br />
<br />
However, it should be noted that once a window has been 'snapped' to an edge, it will remain vertically maximised unless subsequently maximised and then restored. The solution is to implement additional keybinds - in this instance using the {{ic|down}} and {{ic|up}} keys - to do so. This will also make pulling 'snapped' windows from screen edges faster as well:<br />
<br />
<keybind key="W-Down"><br />
<action name="Unmaximize"/><br />
</keybind><br />
<keybind key="W-Up"><br />
<action name="Maximize"/><br />
</keybind><br />
<br />
This [http://ubuntuforums.org/showthread.php?t=1796793 Ubuntu forum thread] provides more information. Applications such as {{AUR|opensnap}} are also available to automatically simulate window snapping behaviour without the use of keybinds.<br />
Another option is to use {{AUR|bunsen-utilities-git}} which provides {{ic|bl-aerosnap --left}} and {{ic|bl-aerosnap --right}} commands which will snap active window on left or right edge respectively if it's not snapped and restore it to original size and position otherwise. Just bind these commands to the key combination of your choosing.<br />
<br />
=== Smooth display manager transition ===<br />
<br />
{{Note|This has been confirmed to work with [[LightDM]].}}<br />
<br />
Users of display managers might experience a flickering during the transition between the display manager and the Openbox desktop. The flickering comes from Openbox setting the root window's color during startup. Therefore there's a brief moment when the display flashes in a grey color, between the display manager's background and the desktop's wallpaper.<br />
<br />
Setting the root window's background color can be disabled by editing the Openbox startup script found in {{ic|/usr/lib/openbox/openbox-autostart}}. Simply comment out (or delete) the block starting with {{ic|# Set a background color}}.<br />
<br />
{{Note|Users who don't specifically set their wallpaper will "inherit" the display manager's background automatically if they disable the root window color adjustment.}}<br />
<br />
=== Window Decorations ===<br />
<br />
To remove window decorations for all or particular applications, use the ''<decor>'' option in the ''<applications>'' section of ''rc.xml'' (user: ''~/.config/openbox/'' or system: ''/etc/xdg/openbox/'').<br><br />
Example for Firefox, including variants like Firefox-Beta and Firefox-Nightly:<br />
<application class="Firefox*"><br />
<decor>no</decor><br />
</application><br />
One could also disable decorations for all applications (using class '''"*"'''), then enable them (using '''yes''') for individual ones. To apply the changes, restart your desktop session, and thus Openbox. Reference: [http://openbox.org/wiki/Help:FAQ#How_do_I_remove_the_decorations_from_all_my_windows.3F Openbox FAQ]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Firefox ===<br />
<br />
Mozilla based browsers may ignore application rules (e.g. {{ic|<desktop>}}) unless {{ic|1=class="Firefox"}} is used. See [[#Xprop values for applications]].<br />
<br />
=== Missing themes ===<br />
<br />
If for any reason the newly extracted theme cannot be selected, open the theme directory to first ensure that it is compatible with Openbox - there should be an {{ic|openbox-3}} directory and a {{ic|themerc}} file within it. An {{ic|.obt}} ('''O'''pen'''B'''ox '''T'''heme) file may also be present in some instances, which can then be manually loaded in {{Pkg|obconf}}.<br />
<br />
A theme may also be not accessible due to wrong permissions. See [[File permissions and attributes]] for more.<br />
<br />
=== Stop continuous desktop switching ===<br />
<br />
By default Openbox switches from the last desktop back to the first desktop on mouse wheel scroll. Use {{ic|<wrap>no</wrap>}} in the {{ic|mousebind}} section to disable this behaviour.<br />
<br />
<context name="Desktop"><br />
<mousebind button="Up" action="Click"><br />
<action name="GoToDesktop"><br />
<to>previous</to><br />
<wrap>no</wrap><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name="GoToDesktop"><br />
<to>next</to><br />
<wrap>no</wrap><br />
</action><br />
</mousebind><br />
</context><br />
<br />
=== Windows load behind the active window ===<br />
<br />
Some application windows (such as Firefox windows) may load behind the currently active window, causing you to need to switch to the window you just created to focus it. To fix this behavior add this to your {{ic|~/.config/openbox/rc.xml}} file, inbetween the {{ic|1=<openbox_config>}} and {{ic|1=</openbox_config>}} tags:<br />
<br />
{{bc|1=<br />
<applications><br />
<application class="*"><br />
<focus>yes</focus><br />
</application><br />
</applications><br />
}}<br />
<br />
== See also ==<br />
<br />
* [http://openbox.org/ Openbox Website] - Official website<br />
* [http://www.box-look.org/ Box-Look.org] - A good resource for themes and related artwork<br />
* [https://bbs.archlinux.org/viewtopic.php?id=93126 Openbox Hacks and Configs Thread] @ Arch Linux Forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=45692 Openbox Screenshots Thread] @ Arch Linux Forums<br />
* [http://urukrama.wordpress.com/openbox-guide/ An Openbox guide]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Openbox&diff=566965Openbox2019-02-20T21:53:50Z<p>Phil.r.dubois: /* Themes */ Changed "and" to "or" in the first sentence, since only one of these two packages is required.</p>
<hr />
<div>[[Category:Stacking WMs]]<br />
[[cs:Openbox]]<br />
[[de:Openbox]]<br />
[[el:Openbox]]<br />
[[es:Openbox]]<br />
[[fr:Openbox]]<br />
[[it:Openbox]]<br />
[[ja:Openbox]]<br />
[[ko:Openbox]]<br />
[[lt:Openbox]]<br />
[[nl:Openbox]]<br />
[[pl:Openbox]]<br />
[[ru:Openbox]]<br />
[[sk:Openbox]]<br />
[[sr:Openbox]]<br />
[[zh-hans:Openbox]]<br />
[[zh-hant:Openbox]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Display manager}}<br />
{{Related|File manager functionality}}<br />
{{Related|Xdg-menu}}<br />
{{Related|Oblogout}}<br />
{{Related articles end}}<br />
<br />
[http://openbox.org/wiki/Main_Page Openbox] is a lightweight, powerful, and highly configurable ''stacking'' [[window manager]] with extensive standards support. It may be built upon and run independently as the basis of a unique [[desktop environment]], or within other integrated desktop environments such as [[KDE]] and [[Xfce]], as an alternative to the window managers they provide. The [[LXDE]] desktop environment is itself built around Openbox.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openbox}} package.<br />
<br />
== Starting ==<br />
<br />
=== Standalone ===<br />
<br />
Run {{ic|openbox}} or {{ic|openbox-session}} with [[xinit]]. Note that only {{ic|openbox-session}} provides [[#Autostart]].<br />
<br />
{{Note|After executing openbox-session, there is only a blank grey screen. Try to move your mouse and '''right click''' to get an openbox menu to make sure that it is actually working.}}<br />
<br />
=== Other desktop environments ===<br />
<br />
{{Note|<br />
* When replacing the native window manager of a [[desktop environment]] with Openbox, keep in mind that Openbox does not provide any compositing effects (such as transparency). See [[#Compositing effects]].<br />
* Openbox does work with GNOME applications (but see [[GTK+#Client-side decorations]]). [http://comments.gmane.org/gmane.comp.window-managers.openbox/6595]}}<br />
<br />
See [[Desktop environment#Use a different window manager]].<br />
<br />
== Configuration==<br />
<br />
{{Note|Local configuration files will always override global equivalents.}}<br />
<br />
Four key files form the basis of the [http://openbox.org/wiki/Configuration openbox configuration], each serving a unique role. They are: {{ic|rc.xml}}, {{ic|menu.xml}}, {{ic|autostart}}, and {{ic|environment}}. Although these files are discussed in more detail below, to start configuring Openbox, it will first be necessary to create a '''local''' Openbox profile (i.e for your specific user account) based on them. This can be done by copying them from the '''global''' {{ic|/etc/xdg/openbox}} profile (applicable to any and all users) as a template:<br />
<br />
$ cp -R /etc/xdg/openbox ~/.config/<br />
<br />
=== rc.xml ===<br />
<br />
{{Tip|Custom keyboard shortcuts (keybindings) must be added to the {{ic|<keyboard>}} section of this file, and underneath the {{ic|<nowiki><!-- Keybindings for running aplications --></nowiki>}} heading.}}<br />
<br />
{{ic|~/.config/openbox/rc.xml}} is the main configuration file, responsible for determining the behaviour and settings of the overall session, including:<br />
<br />
* Keyboard shortcuts (e.g. starting applications; controlling the volume)<br />
* Theming<br />
* Desktop and Virtual desktop settings, and<br />
* Application Window settings<br />
<br />
This file is also pre-configured, meaning that it will only be necessary to amend existing content in order to customise behaviour to suit personal preference.<br />
<br />
{{Note|Per-application settings pertaining to fixed placement of applications per monitor will only work if the x & y position have also been defined.}}<br />
<br />
=== menu.xml ===<br />
<br />
{{ic|~/.config/openbox/menu.xml}} defines the type and behaviour of the desktop menu, accessable by right-clicking the background. Although the default provided is a '''static menu''' (meaning that it will not automatically update when new applications are installed), it is possible to employ the use of '''dynamic menus''' that will automatically update as well. <br />
<br />
The available options are discussed extensively below in the [[#Menus]] section.<br />
<br />
=== Autostart ===<br />
<br />
{{ic|openbox-session}} provides two autostart mechanisms: [[XDG Autostart]] (which only works if {{Pkg|python2-xdg}} is installed) and [http://openbox.org/wiki/Help:Autostart Openbox's own autostart mechanism].<br />
<br />
Openbox's own autostart mechanism:<br />
<br />
* sources {{ic|/etc/xdg/openbox/environment}}<br />
* sources {{ic|~/.config/openbox/environment}}<br />
* runs {{ic|/etc/xdg/openbox/autostart}}<br />
* runs {{ic|~/.config/openbox/autostart}}<br />
<br />
Issues regarding commands in {{ic|~/.config/openbox/autostart}} being executed out of order (or skipped altogether) are often resolved by the addition of small delays. For instance:<br />
<br />
xset -b<br />
(sleep 3s && nm-applet) &<br />
(sleep 3s && conky) &<br />
<br />
=== environment ===<br />
<br />
{{ic|~/.config/openbox/environment}} can be used to export and set relevant environmental variables such as to:<br />
<br />
* Define new pathways (e.g. execute commands that would otherwise require the entire pathway to be listed with them)<br />
* Change language settings, and<br />
* Define other variables to be used (e.g. the fix for GTK theming could be listed here)<br />
<br />
=== Themes ===<br />
<br />
Install {{Pkg|obconf}} or {{Pkg|lxappearance-obconf}} for a GUI to configure visual settings and theming.<br />
<br />
A good selection of themes are available in the {{Pkg|openbox-themes}} package or the [[AUR]]. Some [[GTK+#Themes]] come with an Openbox theme as well. Both Openbox-specific and Openbox-compatible themes will be installed to the {{ic|/usr/share/themes}} directory and will also be immediately available for selection.<br />
<br />
[https://www.box-look.org/browse/ord/latest/ box-look.org] is an excellent and well-established source of themes. [http://www.deviantart.com/ deviantART.com] is another excellent resource. Many more can be found online.<br />
<br />
==== Edit or create ====<br />
<br />
{{Tip|It's better to copy a theme to your home directory than to edit those found in {{ic|/usr/share/themes/}}. This will retain the original should anything go wrong and ensure that your changes are not overwritten on update.}}<br />
<br />
The process of creating new or modifying existing themes is covered extensively at the official [http://openbox.org/wiki/Help:Themes openbox.org] website. {{AUR|obtheme}} is a user-friendly GUI for doing so.<br />
<br />
=== GUI configuration ===<br />
<br />
Several GUI applications are available to quickly and easily configure your Openbox desktop.<br />
<br />
* {{App|ObConf|A GTK2 based configuration tool for the Openbox window manager.|http://openbox.org/wiki/ObConf:About|{{Pkg|obconf}}}}<br />
* {{App|LXAppearance ObConf|Plugin for LXAppearance to configure Openbox. Note that not all options to configure Openbox are available in this plugin, so you might want to install obconf anyway.|http://lxde.org|{{Pkg|lxappearance-obconf}}}}<br />
* {{App|LXInput|LXDE keyboard and mouse configuration|http://lxde.org|{{Pkg|lxinput}}}}<br />
* {{App|LXRandR|LXDE monitor configuration.|http://wiki.lxde.org/en/LXRandR|{{Pkg|lxrandr}}}}<br />
* {{App|obkey|Configure Openbox keyboard shortcuts|https://code.google.com/p/obkey/|{{AUR|obkey}}}} <br />
* {{App|ob-autostart|A simple autostart application for Openbox.|http://pastebin.com/012YgXTk|{{AUR|ob-autostart}}}} <br />
* {{App|obapps|Graphical tool for configuring application settings in Openbox.|https://sourceforge.net/projects/obapps/|{{AUR|obapps}}}} <br />
<br />
Programs and applications relating to the configuration of Openbox's desktop menu are discussed in the [[#Menus|Menus]] section.<br />
<br />
== Openbox reconfiguration ==<br />
<br />
{{Tip|where not already present, it would be worthwhile adding this command to a menu and/or as a keybind for convenience.}}<br />
<br />
Openbox will not always automatically reflect any changes made to its configuration files within a session. As a consequence, it will be necessary to manually reload those files after they have been edited. To do so, enter the following command:<br />
<br />
$ openbox --reconfigure<br />
<br />
Where intending to add this command as a keybind to {{ic|~/.config/openbox/rc.xml}}, it will only be necessary to list the command as {{ic|reconfigure}}. An example has been provided below, using the {{ic|Super}}+{{ic|F11}} keybind:<br />
<br />
<keybind key="W-F11"><br />
<action name="Reconfigure"/><br />
</keybind><br />
<br />
== Keybinds ==<br />
<br />
All keybinds must be added to the {{ic|~/.config/openbox/rc.xml}} file, and below the {{ic|<nowiki><!-- Keybindings for running aplications --></nowiki>}} heading. Although a brief overview has been provided here, a more in-depth explanation of keybindings can be found at [http://openbox.org/wiki/Help:Bindings openbox.org]. <br />
<br />
Keybinds can be added to the configuration file using the following syntax:<br />
<br />
<keybind key="'''my-key-combination'''"><br />
<action name="'''my-action'''"><br />
'''...'''<br />
</action><br />
</keybind><br />
<br />
The action name for running an external command is ''Execute''. Use the following syntax to define an external command to execute:<br />
<br />
<action name="Execute"><br />
<command>'''my-command'''</command><br />
</action><br />
<br />
See [http://openbox.org/wiki/Help:Actions the Openbox wiki] for a list of all available actions.<br />
<br />
{{Tip|The {{AUR|obkey}} utility provides a graphical interface for configuring key bindings. Before using ''obkey'', you should use ''obconf'' to create {{ic|~/.config/openbox/rc.xml}}.}}<br />
<br />
While the use of standard alpha-numeric keys for keybindings is self-explanatory, special names are assigned to other types of keys, such as {{ic|modifiers}}, {{ic|multimedia}} and {{ic|navigation}}.<br />
<br />
=== Modifiers ===<br />
<br />
{{ic|Modifier}} keys play an important role in keybindings (e.g. holding down the {{ic|shift}} or {{ic|CTRL / control}} key in combination with another key to undertake an action). Using modifiers helps to prevent conflicting keybinds, whereby two or more actions are linked to the same key or combination of keys. The syntax to use a modifier with another key is:<br />
<br />
"<modifier>-<key>"<br />
<br />
The modifier codes are as follows:<br />
<br />
* {{ic|S}}: Shift<br />
* {{ic|C}}: Control / CTRL<br />
* {{ic|A}}: Alt<br />
* {{ic|W}}: Super / Windows<br />
* {{ic|M}}: Meta<br />
* {{ic|H}}: Hyper (If it is bound to something)<br />
<br />
=== Multimedia keys ===<br />
<br />
Where available, it is possible to set the appropriate {{ic|multimedia}} keys to perform their intended functions, such as to control the volume and/or the screen brightness. These will usually be integrated into the {{ic|function}} keys, and are identified by their appropriate symbols. See [[Extra keyboard keys]] for details.<br />
<br />
The volume and brightness multimedia codes are as follows (note that commands will still have to be assigned to them to actually function):<br />
<br />
* {{ic|XF86AudioRaiseVolume}}: Increase volume<br />
* {{ic|XF86AudioLowerVolume}}: Decrease volume<br />
* {{ic|XF86AudioMute}}: Mute / unmute volume<br />
* {{ic|XF86MonBrightnessUp}}: Increase screen brightness<br />
* {{ic|XF86MonBrightnessDown}}: Decrease screen brightness<br />
<br />
For a full list of XF86 multimedia keys, see the [http://wiki.linuxquestions.org/wiki/XF86_keyboard_symbols LinuxQuestions wiki].<br />
<br />
==== Volume control ====<br />
<br />
What commands should be used for controlling the volume will depend on whether [[ALSA]], [[PulseAudio]], or [[OSS]] is used for sound.<br />
<br />
*ALSA: see [[Advanced Linux Sound Architecture#Keyboard volume control]].<br />
*PulseAudio: see [[PulseAudio#Keyboard volume control]]<br />
*OSS: see [[OSS#Using multimedia keys with OSS]].<br />
<br />
=== Navigation keys ===<br />
<br />
These are the directional / arrow keys, usually used to move the cursor up, down, left, or right. The (self-explanatory) navigation codes are as follows:<br />
<br />
* {{ic|Up}}: Up<br />
* {{ic|Down}}: Down<br />
* {{ic|Left}}: Left<br />
* {{ic|Right}}: Right<br />
<br />
== Menus ==<br />
<br />
It is possible to employ three types of menu in Openbox: {{ic|static}}, {{ic|pipes}} (dynamic), and {{ic|generators}} (static or dynamic). They may also be used alone or in any combination.<br />
<br />
=== Static ===<br />
<br />
As the name would suggest, this default type of menu does not change in any way, and may be manually edited and/or (re)generated automatically through the use on an appropriate software package.<br />
<br />
Fast and efficient, while this type of menu can be used to select applications, it can also be useful to access specific functions and/or perform specific tasks (e.g. desktop configuration), leaving the access of applications to another process (e.g. the {{Pkg|synapse}} or {{Pkg|xfce4-appfinder}} applications).<br />
<br />
The {{ic|~/.config/openbox/menu.xml}} file will be the sole source of static desktop menu content.<br />
<br />
==== menumaker ====<br />
<br />
{{Pkg|menumaker}} automatically generates {{ic|xml}} menus for several window managers, including Openbox, [[Fluxbox]], [[IceWM]] and [[Xfce]]. It will search for all installed executable programs and consequently create a menu file for them. It is also possible to configure MenuMaker to exclude certain application types (e.g. relating to [[GNOME]] or [[KDE]]), if desired.<br />
<br />
Once installed and executed, it will automatically generate a new {{ic|~/.config/openbox/menu.xml}} file. To avoid overwriting an existing file, enter:<br />
<br />
$ mmaker -v OpenBox3<br />
<br />
Otherwise, to overwrite an existing file, add the {{ic|force}} argument ({{ic|f}}):<br />
<br />
$ mmaker -vf OpenBox3<br />
<br />
Once a new {{ic|~/.config/openbox/menu.xml}} file has been generated it may then be manually edited, or configured using a GUI menu editor, such as {{Pkg|obmenu}}.<br />
<br />
==== obmenu ====<br />
<br />
{{Warning|{{ic|obm-xdg}} - a pipe menu to generate a list of [[GTK+]] and [[GNOME]] applications - is also provided with obmenu. However, it has long-running bugs whereby it may produce an invalid output, or even not function at all. Consequently it has been omitted from discussion.}}<br />
<br />
{{Pkg|obmenu}} is a "user-friendly" GUI application to edit {{ic|~/.config/openbox/menu.xml}}, without the need to code in {{ic|xml}}.<br />
<br />
==== xdg-menu ====<br />
<br />
{{Pkg|archlinux-xdg-menu}} will automatically generate a menu based on {{ic|xdg}} files contained within the {{ic|/etc/xdg/}} directory for numerous Window Managers, including Openbox. Review the [[Xdg-menu#OpenBox]] article for further information.<br />
<br />
==== logout menu options ====<br />
<br />
{{Tip|The commands provided can also be attached to [[#Keybinds|keybinds]].}}<br />
<br />
The {{ic|~/.config/openbox/menu.xml}} file can be edited in order to provide a sub-menu with the same options as provided by [[#oblogout|oblogout]]. The sample script below will provide all of these options, with the exception of the ability to lock the screen:<br />
<br />
<menu id="exit-menu" label="Exit"><br />
<item label="Log Out"><br />
<action name="Execute"><br />
<command>openbox --exit</command><br />
</action><br />
</item><br />
<item label="Shutdown"><br />
<action name="Execute"><br />
<command>systemctl poweroff</command><br />
</action><br />
</item><br />
<item label="Restart"><br />
<action name="Execute"><br />
<command>systemctl reboot</command><br />
</action><br />
</item><br />
<item label="Suspend"><br />
<action name="Execute"><br />
<command>systemctl suspend</command><br />
</action><br />
</item><br />
<item label="Hibernate"><br />
<action name="Execute"><br />
<command>systemctl hibernate</command><br />
</action><br />
</item><br />
</menu><br />
<br />
Once the entries have been composed, add the following line to present the sub-menu where desired within the main desktop menu (usually as the last entry):<br />
<br />
<menu id="exit-menu"/><br />
<br />
=== Pipes ===<br />
<br />
{{Tip|It is entirely feasible for a static menu to contain one or more pipe sub-menus. The functionality of some pipe menus may also rely on the installation of relevant software packages.}}<br />
<br />
This type of menu is in essence a script that provides dynamic, refreshed lists on-the-fly as and when run. These lists may be used for multiple purposes, including to list applications, to provide information, and to provide control functions. Pre-configured pipe menus can be installed, although not from the [[official repositories]]. More experienced users can also modify and/or create their own custom scripts. Again, {{ic|~/.config/openbox/menu.xml}} may and commonly will contain several pipe menus.<br />
<br />
==== Examples ====<br />
<br />
* {{AUR|openbox-xdgmenu}}: fast xdg-menu converter to xml-pipe-menu<br />
* {{AUR|obfilebrowser}}: Application and file browser<br />
* {{AUR|obdevicemenu}}: Management of removable media with [[Udisks]]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1345031 wifi pipe menu]: Wireless networking using [[Netctl]]<br />
<br />
[http://openbox.org/wiki/Openbox:Pipemenus Openbox.org] also provides a further list of pipe menus.<br />
<br />
=== Generators ===<br />
<br />
This type of menu is akin to those provided by the taskbars of desktop environments such as [[Xfce]] or [[LXDE]]. Automatically updating on-the-fly, this type of menu can be powerful and very convenient. It may also be possible to add custom categories and menu entries; read the documentation for your intended dynamic menu to determine if and how this can be done.<br />
<br />
A menu generator will have to be executed from the {{ic|~/.config/openbox/menu.xml}} file.<br />
<br />
==== obmenu-generator ====<br />
<br />
{{Tip|icons can still be disabled in {{AUR|obmenu-generator}}, even where enabled in {{ic|~/.config/openbox/rc.xml}}.}}<br />
<br />
{{AUR|obmenu-generator}} is highly recommended despite being an unofficial package. With the ability to be used as a static or dynamic menu, it is highly configurable, powerful, and versatile. Menu categories and individual entries may also be easily hidden, customised, and/or added with ease. The [http://trizenx.blogspot.co.uk/2012/02/obmenu-generator.html official homepage] provides further information and screenshots.<br />
<br />
Below is an example of how obmenu-generator would be dynamically executed without icons in {{ic|~/.config/openbox/menu.xml}}:<br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<openbox_menu><br />
<menu id="root-menu" label="OpenBox 3" execute="/usr/bin/obmenu-generator"><br />
</menu><br />
</openbox_menu><br />
<br />
To automatically iconify entries, the {{ic|-i}} option would be added:<br />
<br />
<menu id="root-menu" label="OpenBox 3" execute="/usr/bin/obmenu-generator -i"><br />
<br />
==== openbox-menu ====<br />
<br />
{{Tip|If this menu produces an error, it may be solved by enabling icons in {{ic|~/.config/openbox/rc.xml}}.}}<br />
<br />
{{AUR|openbox-menu}} uses the [[LXDE]] [http://sourceforge.net/projects/lxde/files/menu-cache/ menu-cache] to create dynamic menus. The [http://fabrice.thiroux.free.fr/openbox-menu_en.html official homepage] provides further information and screenshots.<br />
<br />
=== Menu icons ===<br />
<br />
To show icons next to menu entries, it will be necessary to ensure they are enabled in the {{ic|<menu>}} section of the {{ic|~/.config/openbox/rc.xml}} file:<br />
<br />
<applicationIcons>yes</applicationIcons><br />
<br />
Where using a static menu, it will then be necessary to edit the {{ic|~/.config/openbox/menu.xml}} file to provide both the {{ic|icon <nowiki>=</nowiki>}} command, along with the full path and icon name for each entry. An example of the syntax used to provide an icon for a category is:<br />
<br />
<menu id="apps-menu" label="[label name]" icon="[pathway to icon]/[icon name]"><br />
<br />
=== Desktop menu as a panel menu ===<br />
<br />
{{Tip|XDoTool can simulate any keybind for any action, and as such, it may therefore be used for many other purposes...}}<br />
<br />
[[xdotool]] is a package that can issue commands to simulate key presses / keybinds, meaning that it is possible to use it to invoke keybind-related actions without having to actually press their assigned keys. As this includes the ability to invoke an assigned keybind for the Openbox desktop menu, it is therefore possible to use XDoTool to turn the Openbox desktop menu into a panel menu. Especially where the desktop menu is heavily customised and feature-rich, this may prove very useful to:<br />
<br />
* Replace an existing panel menu<br />
* Implement a panel menu where otherwise not provided or possible (e.g. for [[Tint2]])<br />
* Compensate where losing access to the desktop menu due to the use of an application like {{pkg|xfdesktop}} to manage the [[#Desktop icons and wallpapers|desktop]].<br />
<br />
Once XDoTool has been installed - if not already present - it will be necessary to create a keybind to access the root menu in {{ic|~/.config/openbox/rc.xml}}, and again below the {{ic|<nowiki><</nowiki>!-- Keybindings for running aplications --<nowiki>></nowiki>}} heading. For example, the following code will bring up the menu by pressing {{ic|CTRL}} + {{ic|m}}:<br />
<br />
<keybind key="C-m"><br />
<action name="ShowMenu"><br />
<menu>root-menu</menu><br />
</action><br />
</keybind><br />
<br />
Openbox must then be [[#Openbox reconfiguration|reconfigured]]. In this instance, XDoTool will be used to simulate the {{ic|CTRL}} + {{ic|m}} keypress to access the desktop menu with the following command (note the use of {{ic|+}} in place of {{ic|-}}):<br />
<br />
xdotool key control+m<br />
<br />
How this command may be used as a panel launcher / icon is largely dependent on the features of panel used. While some panels will allow the above command to be executed directly in the process of creating a new launcher, others may require the use of an executable script. As an example, a custom executable script called {{ic|obpanelmenu.sh}} will be created in the {{ic|~/.config}} folder:<br />
<br />
$ ''text editor'' ~/.config/obpanelmenu.sh<br />
<br />
Once the empty file has been opened, the appropriate XDoTool command must be added to the empty file (i.e. to simulate the {{ic|CTRL}} + {{ic|m}} keypress for this example):<br />
<br />
xdotool key control+m<br />
<br />
After the file has been saved and closed, it may then be made into an executable script with the following command:<br />
<br />
$ chmod +x ~/.config/obpanelmenu.sh<br />
<br />
Executing it will bring up the Openbox desktop menu. Consequently, where using a panel that supports drag-and-drop functionality to add new launchers, simply drag the executable script onto it before changing the icon to suit personal taste.<br />
<br />
=== XDG compliant menu ===<br />
<br />
A xdg compliant menu is based on the freedesktop.org standard. The menu is defined in menu-files which reside in /etc/xdg/menus. New applications will occur automatically in the menu.<br />
<br />
==== Examples ====<br />
<br />
* [https://github.com/mlde/californium californium]: xdg menu based on the LXQt main menu and easily themable<br />
<br />
== Tips and tricks ==<br />
<br />
=== Cursor and icon themes ===<br />
<br />
See [[Cursor themes]] and [[Icons]] for details.<br />
<br />
=== Desktop icons and wallpapers ===<br />
<br />
Openbox does not natively support the use of desktop icons or wallpapers.<br />
<br />
See [[PCManFM#Desktop management|PCManFM]], [[SpaceFM#Desktop management|SpaceFM]] and [[Idesk]].<br />
<br />
{{note|You may have to edit {{ic|~/.conkyrc}} and set {{ic|own_window_type}} to {{ic|normal}}.}}<br />
<br />
See [[List of applications#Wallpaper setters]].<br />
<br />
=== Compositing effects ===<br />
<br />
Openbox does not provide native support for [[Wikipedia:Compositing window manager|compositing]], and thus requires an external compositor for this purpose.<br />
<br />
Although compositing is not a necessary component, it may specifically avoid issues such as screen distortion with [[#oblogout|oblogout]], and visual glitches with terminal window transparency. See [[Xorg#Composite]] for common choices.<br />
<br />
=== oblogout ===<br />
<br />
See the [[Oblogout]] article for an overview on how to use this useful, graphical logout script.<br />
<br />
=== Openbox for multihead users ===<br />
<br />
While Openbox provides better than average multihead support on its own, {{AUR|openbox-multihead-git}} provides a development branch called '''Openbox Multihead''' that gives multihead users per-monitor desktops. This model is not commonly found in floating window managers, but exists mainly in tiling window managers. It is explained well on the [http://xmonad.org/tour.html#workspace Xmonad web site]. Also, please see [https://github.com/BurntSushi/openbox-multihead/blob/multihead/README.MULTIHEAD README.MULTIHEAD] for a more comprehensive description of the new features and configuration options found in Openbox Multihead.<br />
<br />
Openbox Multihead will function like normal Openbox when only a single head is available.<br />
<br />
A downside to using Openbox Multihead is that it breaks the EWMH assumption that one and only one desktop is visible at any time. Thus, existing pagers will not work well with it. To remedy this, you can install {{AUR|pager-multihead-git}}{{Broken package link|{{aur-mirror|pager-multihead-git}}}} alongside Openbox Multihead. It will work without Openbox Multihead if only one monitor is active.<br />
<br />
=== Launch a complex command with hotkey ===<br />
<br />
If you need to execute a complex command, use shell functionality.<br />
<br />
Special character replacement are as follows:<br />
<br />
* {{ic|&}}: &amp;amp;<br />
* {{ic|<}}: &amp;lt;<br />
* {{ic|>}}: &amp;gt;<br />
<br />
This example will turn off display immediately and lock screen with {{Pkg|slock}}. It was taken from [https://bbs.archlinux.org/viewtopic.php?pid=903057 this thread].<br />
<keybind key="W-l"><br />
<action name="Execute"><br />
<command>sh -c 'slock &amp;amp; (sleep .5 &amp;amp;&amp;amp; xset dpms force off)'</command><br />
</action><br />
</keybind><br />
<br />
Sometimes one need to specify environment variable for application:<br />
<keybind key="A-F7"><br />
<action name="Execute"><br />
<command>sh -c "LC_ALL=C obconf"</command><br />
</action><br />
</keybind><br />
<br />
Another example will launch application preserving all stdout and stderr output to file:<br />
<keybind key="A-f"><br />
<action name="Execute"><br />
<command>sh -c sh -c "exec gimp &amp;gt;/tmp/gimp.out 2&amp;gt;&amp;amp;1"</command><br />
</action><br />
</keybind><br />
<br />
=== Switch desktops using the mouse ===<br />
<br />
It is possible to switch desktop by moving the mouse cursor to the edges of the screen. First install {{Pkg|xdotool}} and add the following two lines to your {{ic|~/.xinitrc}}:<br />
<br />
xdotool behave_screen_edge --delay 500 left set_desktop --relative -- -1 &<br />
xdotool behave_screen_edge --delay 500 right set_desktop --relative -- +1 &<br />
<br />
=== Set default applications / file associations ===<br />
<br />
See the [[Default applications]] article.<br />
<br />
=== Ad-hoc window transparency ===<br />
<br />
{{Warning|This may not work where other actions are defined within the action group.}}<br />
The program {{Pkg|transset-df}} can enable window transparency on-the-fly.<br />
<br />
For example, using the following code in the {{ic|<mouse>}} section of the {{ic|~/.config/openbox/rc.xml}} file will enable control of application window transparency by hovering the mouse-pointer over the title bar and scrolling with the middle button:<br />
<br />
<context name="Titlebar"><br />
...<br />
<mousebind button="Up" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --inc </execute><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --dec </execute><br />
</action><br />
</mousebind><br />
...<br />
</context><br />
<br />
=== Using obxprop for faster configuration ===<br />
<br />
The {{Pkg|openbox}} package provides a {{ic|obxprop}} binary that can parse relevant values for applications settings in {{ic|rc.xml}}. Officially {{ic|<nowiki>obxprop | grep "^_OB_APP"</nowiki>}} is recommended for this task. Start the process by running the command shown, then click a window to see its properties in the terminal.<br />
<br />
=== Xprop values for applications ===<br />
<br />
{{Pkg|xorg-xprop}} can be used to relay property values for selected applications. Where frequently using per-application settings, the following [[Bash#Aliases|Bash Alias]] may be useful:<br />
dy:<br />
<br />
alias xp='xprop | grep "WM_WINDOW_ROLE\|WM_CLASS" && echo "WM_CLASS(STRING) = \"NAME\", \"CLASS\""'<br />
<br />
To use Xorg-XProp, run using the alias given {{ic|xp}}, and click on the active program desired to define with per-application settins. The results displayed will only be the information that Openbox itself requires, namely the {{ic|WM_WINDOW_ROLE}} and {{ic|WM_CLASS}} (name and class) values:<br />
<br />
WM_WINDOW_ROLE(STRING) = "roster"<br />
WM_CLASS(STRING) = "gajim.py", "Gajim.py"<br />
WM_CLASS(STRING) = "NAME", "CLASS"<br />
<br />
=== Switching between keyboard layouts ===<br />
<br />
See the article section [[Keyboard configuration in Xorg#Switching between keyboard layouts|switching between keyboard layouts]] for instructions.<br />
<br />
=== Set grid layout for virtual desktops ===<br />
<br />
Install {{AUR|obsetlayout}}. To set a 2x2 grid for example:<br />
<br />
obsetlayout 0 2 2 0<br />
<br />
Run it without arguments to know what the arguments mean.<br />
<br />
=== Enable Hot Corners ===<br />
<br />
[https://github.com/mlde/lead lead] provides hot corners for openbox and other lightweight window managers. Start the application with a entry in the autostart-file:<br />
<br />
mlde.lead &<br />
<br />
Commands can be edited in the configuration file {{ic|~/.config/mlde/lead.conf}}:<br />
<br />
[eDP1]<br />
bottom=<br />
bottomLeft=chromium<br />
bottomRight=thunar<br />
left=<br />
right=<br />
top=<br />
topLeft=mlde.californium toggle<br />
topRight=skippy-xd<br />
<br />
=== Window snapping ===<br />
<br />
Many desktop environments and window managers support ''window snapping'' (e.g. Windows 7 Aero snap), whereby they will automatically snap into place when moved to the edge of the screen. This effect can also be simulated in Openbox through the use of [[#Keybinds|keybinds]] on focused windows. <br />
<br />
As illustrated in the example below, percentages must be used to determine window sizes (see [http://openbox.org/wiki/Help:Actions openbox.org] for further information). In this instance, The {{ic|super}} key is used in conjunction with the {{ic|navigation}} keys:<br />
<br />
<keybind key="W-Left"><br />
<action name="UnmaximizeFull"/><br />
<action name="MaximizeVert"/><br />
<action name="MoveResizeTo"><br />
<width>50%</width><br />
</action><br />
<action name="MoveToEdge"><direction>west</direction></action><br />
</keybind><br />
<keybind key="W-Right"><br />
<action name="UnmaximizeFull"/><br />
<action name="MaximizeVert"/><br />
<action name="MoveResizeTo"><br />
<width>50%</width><br />
</action><br />
<action name="MoveToEdge"><direction>east</direction></action><br />
</keybind><br />
<br />
However, it should be noted that once a window has been 'snapped' to an edge, it will remain vertically maximised unless subsequently maximised and then restored. The solution is to implement additional keybinds - in this instance using the {{ic|down}} and {{ic|up}} keys - to do so. This will also make pulling 'snapped' windows from screen edges faster as well:<br />
<br />
<keybind key="W-Down"><br />
<action name="Unmaximize"/><br />
</keybind><br />
<keybind key="W-Up"><br />
<action name="Maximize"/><br />
</keybind><br />
<br />
This [http://ubuntuforums.org/showthread.php?t=1796793 Ubuntu forum thread] provides more information. Applications such as {{AUR|opensnap}} are also available to automatically simulate window snapping behaviour without the use of keybinds.<br />
Another option is to use {{AUR|bunsen-utilities-git}} which provides {{ic|bl-aerosnap --left}} and {{ic|bl-aerosnap --right}} commands which will snap active window on left or right edge respectively if it's not snapped and restore it to original size and position otherwise. Just bind these commands to the key combination of your choosing.<br />
<br />
=== Smooth display manager transition ===<br />
<br />
{{Note|This has been confirmed to work with [[LightDM]].}}<br />
<br />
Users of display managers might experience a flickering during the transition between the display manager and the Openbox desktop. The flickering comes from Openbox setting the root window's color during startup. Therefore there's a brief moment when the display flashes in a grey color, between the display manager's background and the desktop's wallpaper.<br />
<br />
Setting the root window's background color can be disabled by editing the Openbox startup script found in {{ic|/usr/lib/openbox/openbox-autostart}}. Simply comment out (or delete) the block starting with {{ic|# Set a background color}}.<br />
<br />
{{Note|Users who don't specifically set their wallpaper will "inherit" the display manager's background automatically if they disable the root window color adjustment.}}<br />
<br />
=== Window Decorations ===<br />
<br />
To remove window decorations for all or particular applications, use the ''<decor>'' option in the ''<applications>'' section of ''rc.xml'' (user: ''~/.config/openbox/'' or system: ''/etc/xdg/openbox/'').<br><br />
Example for Firefox, including variants like Firefox-Beta and Firefox-Nightly:<br />
<application class="Firefox*"><br />
<decor>no</decor><br />
</application><br />
One could also disable decorations for all applications (using class '''"*"'''), then enable them (using '''yes''') for individual ones. To apply the changes, restart your desktop session, and thus Openbox. Reference: [http://openbox.org/wiki/Help:FAQ#How_do_I_remove_the_decorations_from_all_my_windows.3F Openbox FAQ]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Firefox ===<br />
<br />
Mozilla based browsers may ignore application rules (e.g. {{ic|<desktop>}}) unless {{ic|1=class="Firefox"}} is used. See [[#Xprop values for applications]].<br />
<br />
=== Missing themes ===<br />
<br />
If for any reason the newly extracted theme cannot be selected, open the theme directory to first ensure that it is compatible with Openbox - there should be an {{ic|openbox-3}} directory and a {{ic|themerc}} file within it. An {{ic|.obt}} ('''O'''pen'''B'''ox '''T'''heme) file may also be present in some instances, which can then be manually loaded in {{Pkg|obconf}}.<br />
<br />
A theme may also be not accessible due to wrong permissions. See [[File permissions and attributes]] for more.<br />
<br />
=== Stop continuous desktop switching ===<br />
<br />
By default Openbox switches from the last desktop back to the first desktop on mouse wheel scroll. Use {{ic|<wrap>no</wrap>}} in the {{ic|mousebind}} section to disable this behaviour.<br />
<br />
<context name="Desktop"><br />
<mousebind button="Up" action="Click"><br />
<action name="GoToDesktop"><br />
<to>previous</to><br />
<wrap>no</wrap><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name="GoToDesktop"><br />
<to>next</to><br />
<wrap>no</wrap><br />
</action><br />
</mousebind><br />
</context><br />
<br />
=== Windows load behind the active window ===<br />
<br />
Some application windows (such as Firefox windows) may load behind the currently active window, causing you to need to switch to the window you just created to focus it. To fix this behavior add this to your {{ic|~/.config/openbox/rc.xml}} file, inbetween the {{ic|1=<openbox_config>}} and {{ic|1=</openbox_config>}} tags:<br />
<br />
{{bc|1=<br />
<applications><br />
<application class="*"><br />
<focus>yes</focus><br />
</application><br />
</applications><br />
}}<br />
<br />
== See also ==<br />
<br />
* [http://openbox.org/ Openbox Website] - Official website<br />
* [http://www.box-look.org/ Box-Look.org] - A good resource for themes and related artwork<br />
* [https://bbs.archlinux.org/viewtopic.php?id=93126 Openbox Hacks and Configs Thread] @ Arch Linux Forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=45692 Openbox Screenshots Thread] @ Arch Linux Forums<br />
* [http://urukrama.wordpress.com/openbox-guide/ An Openbox guide]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Talk:Security&diff=528464Talk:Security2018-07-01T19:02:09Z<p>Phil.r.dubois: /* Password maintenance */ agree</p>
<hr />
<div>==Todo==<br />
*Update "Lockout user after three failed login attempts", file mentioned no longer contains those lines ? <br />
*descriptions/rationale for all the links to other articles (MAC)<br />
*base64 /dev/urandom | dd bs=1 count=10 2>/dev/null<br />
*use (enhanced?) ACL on partitions<br />
*[[Disk quota|quotas]]<br />
*limits/cgroups<br />
*sudo timeout<br />
*DNSSEC<br />
*[[Securely Wipe HDD]]<br />
*[[Using File Capabilities Instead Of Setuid]]<br />
*VNC, proxies, ssl, etc<br />
*rvim/rgvim<br />
*browser security (requestpolicy, noscript, sand-boxing browser)<br />
*PAX/<s>grsecurity</s><br />
*stack protector gcc flag: Put some text in the page indicationg Archlinux has it by default (See: [https://bugs.archlinux.org/task/18864 FS#18864])<br />
* run services as non-root (mention that Arch does this where possible by default - but it needs improvement via feature requests)<br />
* run services in clean namespaces<br />
* run services in chroots<br />
* mention issues with sudo (any X11 application can grab the password, and it is a large setuid binary with potential vulnerabilities)<br />
* describe password expiry policies (chage, passwd -X, etc.)<br />
--[[User:Thestinger|thestinger]] 18:09, 11 January 2011 (EST), --[[User:Det|Det]] ([[User talk:Det|talk]]) 11:35, 3 January 2013 (UTC),<br />
--[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 13:49, 19 April 2013 (UTC)<br />
-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:45, 12 August 2013 (UTC)<br />
<br />
== CentOS Wiki OS Protection Article ==<br />
<br />
Hello,<br />
<br />
This seems to be a good article to cross-reference or to use as a basis to pull in more content here. CC BY SA rights so I suspect it is compatible with the Arch Wiki. http://wiki.centos.org/HowTos/OS_Protection<br />
<br />
I am hoping to pull some content in myself, but I am by no means a security guy. I figured some wiser heads might be able to make better use of it than I or correct any mistakes I might make while attempting to contribute.<br />
<br />
Cheers,<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 22:29, 1 August 2013 (UTC)<br />
<br />
:Of course the information itself is not licensed/licenseable, however the way it is presented is, so you either study the original article and present the same information here in an original way, or you actually adapt some content from that article, but in that case the licence clearly states that you have to credit the original authors, and ''I guess'' you can do it by mentioning the original article in the Summary of your edits, and adding a link to [[Security#See also]].<br />
:Just as a clarification, I know that [[Help:Style#Hypertext metaphor]] states "If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information", however in this case we can't talk about "upstream documentation", that's why the rule doesn't apply and duplication of information is allowed, being CentOS's and Arch's wikis on the "same level" with respect to the information provided.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:33, 3 August 2013 (UTC)<br />
<br />
:: Let's first compare the sections in the two articles and see how they relate:<br />
::* '''Modifying fstab''' -> [[Security#Partitions]].<br />
::* '''Package installs''' -> We have [[Security#Authenticating_packages]] and a note at the bottom of [[Security#Partitions]].<br />
::** We ''definitely'' should talk about [[Pacman#Package_security]] in more depth. That is, we should have a general overview of the function of [[Pacman-key]] and why it is important from a security perspective. [[Pacman-key]] mentions the function of the utility, but not its importance from a security perspective.<br />
::* '''Physical protection''' -> [[Security#Physical_security]]<br />
::* '''Restricting root''' -> We have [[Security#Use_sudo_instead_of_su]] which is a good start, but does not mention [[Ssh#Deny_root_login]]. File system permissions on {{ic|/root}}, which I think by default are not {{ic|700}} (they should be) should be added to [[Security#Filesystem permissions]].<br />
::* '''Umask restrictions''' -> We should talk about {{ic|umask}} in [[Security#Filesystem permissions]].<br />
::* '''Pam modifications''' -> [[Realtime process management]], a wiki page in desperate need of editing.<br />
::* '''Reaping idle users''' -> We should cover this in [[Security#User_setup]].<br />
::* '''Restricting cron and at''' -> We have no equivalent.<br />
::* '''Wireless has to go''' -> Maybe worth talking about, but this is low-priority unless we are willing to write a more detailed section called "Wireless security" that is about more than just "turn off wireless."<br />
::* '''Sysctl Security''' -> Covered in [[Sysctl#TCP/IP stack hardening]], maybe we should just link to this.<br />
::* '''Using TCP Wrappers''' -> I could not find anything on ArchWiki discussing general security practices for {{ic|/etc/hotss}}.<br />
::* '''Beefing up IPTables''' -> Should be adapted into [[Iptables]], but perhaps [[Simple Stateful Firewall]] (an article that has good information, but I am not sure if its name makes sense).<br />
::* '''Tamper Resistance''' -> We should have a section on '''logging''' in general and incorporate tools like this, probably.<br />
::Comments ''highly'' appreciated.<br />
::-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 05:09, 3 August 2013 (UTC)<br />
:::If you want to start working in this direction, go for it! :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 5 August 2013 (UTC)<br />
<br />
== Grsecurity sections ==<br />
<br />
We now have three sections devoted only to Grsecurity. What can we do about this?<br />
<br />
The [https://wiki.archlinux.org/index.php?title=Security&diff=272330&oldid=272327 addition] of [[Security#Grsecurity RBAC]] seems to be redundant. However, I agree that "RBAC" is a better name for Grsecurity's MAC implementaiton than [[Security#Access Control Lists]]. In technical terms ACLs are a subset of RBAC and Grsecurity implmeents both. The Grsecurity patchset [https://www.cs.virginia.edu/~jcg8f/GrsecuritySELinuxCaseStudy.pdf only had ACLs][PDF] back in 2005, and the cited case study mentions (it also refers to SELinux as a RBAC implementation, so perhaps SELinux should also be mentioned there):<br />
<br />
:This implementation of ACLs creates a form of process-based mandatory access control. It is possible to restrict what a process can and cannot do. Additionally, access can be restricted to an object for any user, even root. Further, these restrictions cannot be changed by normal users. The system will soon offer role-based access control as well. <br />
<br />
Probably the right solution for this is:<br />
<br />
* Rename [[Security#Grsecurity RBAC]] to [[Security#Role-Based Access Control]].<br />
* Discuss both SELinux/Grsecurity implementations there. There is no need for the RBAC section to be Grsecurity-specific.<br />
<br />
[[Security#Kernel Hardening]] is only about [[Grsecurity]] but I am not sure if it should be merged into [[Security#Mandatory access control|Mandatory access control]] as suggested.<br />
<br />
* I think it is best to give general recommendations here rather than something like "install Grsecurity to make your kernel secure".<br />
* The right solution is probably to expand [[Security#Kernel Hardening]] and discuss [[Wikipedia:PaX]] and whatnot more generally, mentioning Grsecurity as an implementation. <br />
* I do think [[Security#Kernel Hardening]] should probably be moved lower on the page, closer to [[Security#Mandatory access control]]/[[Security#Network and Firewalls]]/[[Security#Authenticating packages]] since that seems to better suit the logical flow of the article.<br />
<br />
-- [[User:Ndt|Ndt]] ([[User Talk:Ndt|talk]]) 21:36, 4 September 2013 (UTC)<br />
<br />
:I can't comment on the content since I don't know much about it, but allow me to add some notes:<br />
:# The different security models (RBAC, MAC, DAC, ACL, ...) should be compared/described separately from the individual implementations (SELinux, Tomoyo, AppArmor, ...). Meaning there should be separate sections for each group, but mainly ''"RBAC is significantly faster then SELinux."'' does not make much sense.<br />
:# There should always be provided alternatives, not just 1:1 mapping (like in case of RBAC and Grsecurity).<br />
:# Descriptions of both ''groups'' can be provided from multiple perspectives. From my experience, in these situations a comparison table is often the best solution.<br />
:I'm not sure about the [[Security#Kernel Hardening]] section, should it focus only on security options that require patching the Arch kernel, or also those included in Arch kernel but not activated?<br />
:I hope it makes sense...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:09, 4 September 2013 (UTC)<br />
::+1, also on mentioning the other options. I further agree with Ndt, moving [[Security#Kernel Hardening]] down to below (or above?) [[Security#Mandatory_access_control]] and merging the bits for [[Security#Kernel_parameters]] into it is better flow, then any other options that are avail without patching into it, followed by PAX and the existing Grsecurity so those get mentioned just before MAC. If someone wants to work on that: I like the comparison/table [http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html here] maybe it gives some inspiration how to expand. If not, maybe good for See also. (further comparisons are at the bottom of the link). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:05, 5 September 2013 (UTC)<br />
<br />
== Nobody as script user ==<br />
<br />
[[Systemd/cron_functionality#The_pkgstats_service]] article says that it is better to use {{ic|noboby}} for some tipe of scripts. Is there any person who can explain further and add a note in this article?<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:29, 13 September 2013 (UTC)<br />
<br />
: Following the [[Wikipedia:Principle of least privilege|principle of least privilege]] it is logical to run as many scripts as possible as an unprivileged user. But this is not possible always, e.g. when the script needs (write) access to some file(s) to function properly, you need to provide those privileges. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:32, 13 September 2013 (UTC)<br />
::It's not actually a good idea to do this. Processes running as {{ic|nobody}} can ptrace each other, so there is a loss of security if more than one thing is run as that users. Ideally, individual users would be created for each case. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 10:52, 31 March 2014 (UTC)<br />
<br />
== Improving the password section ==<br />
<br />
This is a call for ideas and community effort to improve the password recommendations here. I think it's generally agreed that the password section needs (and has, for a long time, needed) some work.<br />
<br />
What does the password section need? Is it even necessary - does it make sense for someone to get this information from a wiki? How can we back up our statements, so that we know that the password recommendations made aren't just totally arbitrary (e.g, "at least one number ...")? <br />
<br />
Citing sources, I think, is useful here - even though there's an element of password generation that is a matter of opinion, there are many recommendation that can be made that are ''not'' opinion. Just my two cents. - [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 21:51, 29 August 2014 (UTC)<br />
<br />
:A part I question is: <br />
<br />
::''Insecure passwords include... Phrases of known words (e.g., all of the lights, correct horse battery staple), even with character substitution.''<br />
<br />
:How about [http://world.std.com/~reinhold/diceware.html Diceware] (mentioned in [[Disk_encryption#Choosing_a_strong_passphrase]], which is linked to at the end of the section) ? --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:48, 31 August 2014 (UTC)<br />
<br />
::I've added some clarifications to that sentence: [https://wiki.archlinux.org/index.php?title=Security&diff=333453&oldid=333379].<br />
::The whole problem comes down to the bits of entropy of a passphrase: if calculated against brute-force attacks, every character from the chosen set counts, because in general they are not releated to each other. In case of Diceware, the characters inside each word ''are'' related to each other, and instead what is independent are the words themselves, so the bits must be calculated on a per-word basis (it's vulnerable to dictionary attacks, which can be seen as a form of brute-force attack with every word representing a character in a set of 7776). Now, as you can see from the table in [[Wikipedia:Password strength]], a set of 5 Diceware words is equal to e.g. 10 ASCII characters (64 bits); 7 words == 13 ASCII. Nowadays you'd need more than that to be "safe", but in the end it mostly depends on the importance of what you want to protect. Of course if you choose a phrase of words that are also grammatically related with each other, you're exposing it to some smart dictionary attacks, which would further lower the total bits of entropy.<br />
::Actually, that whole section could be questioned, in fact I could make a strong password even with "Root words or common strings followed or preceded by added numbers, symbols, or characters", if I chose enough "root words" and numbers; I could even make a strong password with dictionary words grammatically related, if the sentence was long enough :) I hope it makes it clearer.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:34, 1 September 2014 (UTC)<br />
<br />
:::Thanks for clarifying. Maybe add [[Wikipedia:Password strength]] to the article (it's already linked in [[Wikipedia:Password_cracking]], but it wouldn't hurt here)? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 01:32, 2 September 2014 (UTC)<br />
<br />
::::Link added after merging [[Disk_encryption#Choosing_a_strong_passphrase]]. Still, the whole section is very unorganized :( but at least now all the info is gathered in one place. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:16, 3 September 2014 (UTC)<br />
<br />
:::::First time I ever edit or contribute to a Wiki. I added an example of enforcing a password policy using pam_cracklib [[User:Redsolja|Redsolja]] ([[User talk:Redsolja|talk]]) 15:48, 26 April 2015 (UTC)<br />
<br />
::::::Thank you, very well done for a first edit! — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:34, 27 April 2015 (UTC)<br />
<br />
:In the Choosing secure passwords section, I'd like to point out that we're linking to an unencrypted webpage for testing password entropy... [[User:phil.r.dubois|phil.r.dubois]] ([[User talk:phil.r.dubois|talk]]) 23:30, 18 April 2018 (UTC)<br />
<br />
::Thanks, I originally [https://wiki.archlinux.org/index.php?title=Security&diff=518037&oldid=517999 removed] that part without thinking too much, however that test is completely done on the client in Javascript, so theoretically safely, but still I don't see the point of using a website to do that when proper password managers such as Keepass* do the same right where you should be doing it. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:23, 20 April 2018 (UTC)<br />
<br />
:::That explains why it was there in the first place. But yeah, that's a fair assessment. I'd prefer to choose a password manager over trusting the browser any day. [[User:phil.r.dubois|phil.r.dubois]] ([[User talk:phil.r.dubois|talk]]) 15:30, 20 April 2018 (UTC)<br />
<br />
== Removal of incorrect warning ==<br />
<br />
:''Moved from [[User_talk:thestinger]].'' -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:01, 25 February 2015 (UTC)<br />
<br />
Greetings, I have removed [https://wiki.archlinux.org/index.php?title=Security&diff=307743&oldid=307742 the warning] regarding SHA512 on the password hashing section. It's true that one shouldn't use plain sha512 for password hashing, but that isn't what arch (or other Linux distributions) use or are even able to use. What they call "sha512" is crypt_sha512, analogous to cryptmd5 but with the hash function replaced. Crypt_sha512 is a strong sequential function with a configurable iteration parameter. Normal configurations are fairly slow by default and are configurable to be arbritarily slow. I also updated the text to make it clear that it used an iterated sha512 so that others would be less likely to suffer from your confusion. Cheers. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:39, 24 December 2014 (UTC)<br />
<br />
:I was fully aware that it runs a configurable number of sha512 iterations when I made the change. It's not enough iterations to make up for how cheap it is relative to bcrypt/scrypt and it requires very little memory so it does nothing to counter doing billions of hashes per second on a GPU. I don't care enough to argue about it but you shouldn't assume that it had anything to do with confusion. -- [[User:thestinger|thestinger]] 23:48, 24 December 2014 (UTC)<br />
<br />
::Reverted OP's removal a while ago, so this can be closed. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:23, 19 January 2015 (UTC)<br />
<br />
:::It may not be wrong, but it’s still misleading, and conflicts with the immediately following paragraph. Is there a nice way to change each to satisfy everyone? -- [[User:Charmander|Charmander]] ([[User talk:Charmander|talk]]) 19:12, 19 January 2015 (UTC)<br />
<br />
:: I have rephrased the first sentence of the following paragraph to "''The default Arch hash [[SHA_password_hashes|sha512]] is, however, different than plain SHA512. It is very strong and there is no need to change it.''" in an attempt to remove the inconsistency. Please proof-read this, since I am a no cryptography expert - the '''only''' source I was using was this very discussion. Also I am not native to English, so I can't guarantee I was grammatically correct. Here is the diff to my edit: [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393653&oldid=383265] [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:30, 24 August 2015 (UTC)<br />
<br />
::: I don't understand what this changes - how is the SHA512 sum ''different'' (considering thestinger's argument above) ? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:36, 24 August 2015 (UTC)<br />
<br />
:::: AFAIK the Arch's SHA512 iterates, while plain SHA512 doesn't? Anyway, if what I wrote is wrong, please revert it. But if you do, please do fix the inconsistency in a more competent way. The original phrasing is misleading and just cannot last any more. [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:42, 24 August 2015 (UTC)<br />
<br />
::::: See [https://wiki.archlinux.org/index.php?title=Security&diff=393663&oldid=393653]. Perhaps we should also add how the number of iterations could be increased (maximum is 999 999 999, according to man passwd). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:49, 24 August 2015 (UTC)<br />
<br />
:::::: Added with [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393665&oldid=393663]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:56, 24 August 2015 (UTC)<br />
:::::: edit: going to undo this since I don't know what's meant above with "not enough". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:57, 24 August 2015 (UTC)<br />
<br />
::::::: One more thing. Your phrasing does not state whether or not these 5000 iterations, in association with storing passwords in /etc/shadow, actually are secure. With the nearby warning, an impression is made that in might not be enough and that the wiki advises the user to use something else. You have removed this important sentence: "''It is very strong and there is no need to change it''". If this is appropriate, could you kindly explicitly state whether or not this default Arch's hashing is considered secure enough for normal desktop use? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:00, 24 August 2015 (UTC)<br />
<br />
:::::::: I'm not the expert, but I'd assume 5000 iterations is "not enough". However I don't know if 999 999 999 or any arbitray high amount is "enough" either. This assessment likely changes as hardware gets more powerful, or more efficient methods are discovered.<br />
:::::::: The fact that the hashes are stored in {{ic|/etc/shadow}} should be sufficient, but I don't know how to accurately word that ("can't be copied or cracked" is vague at best). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:05, 24 August 2015 (UTC)<br />
<br />
::::::::: I'm honestly unsure if I'm nitpicking or if this is a serious problem. Anyway I [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393676&oldid=393670 have put] a Template:Expansion. Hope that's OK? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:23, 24 August 2015 (UTC)<br />
<br />
:::::::::: Sure, thanks. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:02, 24 August 2015 (UTC)<br />
<br />
:::::::::::I have practically rewritten the section with [https://wiki.archlinux.org/index.php?title=Security&diff=410426&oldid=409966 these 3 edits], adding lots of links so that people can try to better understand this complicated process.<br />
:::::::::::Functions like bcrypt and scrypt are indeed aimed at making it more expensive to brute-force passwords with custom-hardware attacks, but if we don't tell people how to ''decide'' what function to use, and how to ''set'' it up, a warning like that is only FUD...<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:29, 28 November 2015 (UTC)<br />
<br />
== Let's forget about limits.conf? ==<br />
<br />
Look rapidly at [https://sskaje.me/systemd-ulimit/ this] blog post.<br />
<br />
In short: '''limits.conf is useless''' for systemd daemons, because systemd has it's own ''LimitNOFILE=123456'', ''LimitETC=50K''.<br />
<br />
This is also an issue for desktop users, because users implemented via slices, services and User Manager.<br />
<br />
To set per-user resource-limits, now do the following:<br />
<pre><br />
mkdir -p /etc/systemd/system/user@1000.service.d/<br />
cat > /etc/systemd/system/user@1000.service.d/limits.conf << EOF<br />
[Service]<br />
LimitNFILE=131072<br />
EOF<br />
systemd daemon-reload<br />
systemd restart user@1000<br />
</pre><br />
<br />
'''1000''' -- is a user's uid. Optional.<br />
<br />
The archwiki is full of useless limits.conf documentation, it is time to update it, or i've missing something? [[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 09:51, 16 December 2015 (UTC)<br />
<br />
:: Oops, looks like all this info valid only for dbus-activated user apps like gnome-terminal.<br />
::[[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 14:14, 16 December 2015 (UTC)<br />
<br />
== pam_tally ==<br />
<br />
According to the PAM SAG pam_tally is deprecated and should be replaced by pam_tally2. I suggest to update the page accordingly. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 20:20, 7 February 2016 (UTC)<br />
<br />
:Is the information in the manpage for pam_tally2 accurate? I don't know PAM, and I'm not fully comfortable with changing the page without asking first. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 00:01, 18 June 2016 (UTC)<br />
<br />
::Good you ask, such should indeed be tested before updating. Please check [https://bugs.archlinux.org/task/42120#comment148179] as input when you go about changing the section. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:58, 18 June 2016 (UTC)<br />
<br />
:::If pam_tally2 is going to be deprecated soon anyway in favour of pam_faillock, then updating the page right now seems a bit pointless. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 11:28, 18 June 2016 (UTC)<br />
<br />
::::Well, the faillock module has not landed in the package for years, that part remains to be seen. Updating is useful I think, because due to the nature of the pam project they rarely remove modules (since that can severly break existing installations). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:40, 19 June 2016 (UTC)<br />
<br />
::I've run into a couple of problems:<br />
::#pam_tally, the original one, seems to have a default configuration in place, and I'm not sure what steps are needed to completely disable it. Is it enough to remove its line from {{ic|/etc/pam.d/system-login}}, or is there something more to be done? <br />
::#In [https://bugs.archlinux.org/task/42120#comment148179] it's mentioned that pam_tally2 should be added to account pam_tally2.so in the stack as well, but I don't know this should be done. I've gathered that I need to add the line {{ic|account required pam_tally2.so}} to some account section somewhere, but I don't know which file specifically I should be editing.<br />
::I would suggest that this be left to someone who has a better understanding of how PAM works. --[[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 16:37, 21 June 2016 (UTC)<br />
<br />
== Using systemd for more secure services ==<br />
<br />
I saw [https://lwn.net/SubscriberLink/709755/a3b534d94fc57157/ this article] that lists several options for systemd units to help protect one's system. I think some of these should be added to our article. In particular {{man|5|systemd.exec}} recommends setting/enabling {{ic|ProtectHome}}, {{ic|ProtectSystem}}, {{ic|ProtectKernelTunables}}, {{ic|ProtectControlGroups}}, {{ic|RestrictRealtime}} for most long-running services. Some of these are simple boolean options. Others have different levels that can be set. Lennart lists these and others [https://lwn.net/Articles/709764/ here]. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 19:40, 3 January 2017 (UTC)<br />
:Working on a draft of some ideas here: [[User:Rdeckard/Secure Systemd]] -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:10, 5 January 2017 (UTC)<br />
<br />
== grsecurity End of Support ==<br />
<br />
There was a proposal to archive, I think this is a mistake until we know more about how this shakes out. There have been some rumblings that Gentoo Hardened may take over primary development of a branch of the 3.1 patchset. Alternatively, I've already reached out to the Grsecurity team to ask about individual licensing. As Arch is an open source community, it's not unreasonable that there could be some very reasonable individual license. If so, we could probably move the package to the AUR, and users would need to buy a license.<br />
<br />
Finally, the last released patch was for 4.9, which is a stable kernel branch -- there's no reason to kill the wiki just yet, as 4.9 will not be EOL for a long time.<br />
<br />
[[User:Osteichthyes|Osteichthyes]] ([[User talk:Osteichthyes|talk]]) 23:56, 27 April 2017 (UTC)<br />
<br />
:3.1 doesn't work on Arch since systemd requires at least 3.14 or higher, and I somehow doubt that the Arch developers or TUs are willing to cash out for a grsecurity license. Regarding the stance on 4.9, see this post by the maintainer: https://lists.archlinux.org/pipermail/arch-general/2017-April/043612.html {{Unsigned|19:05, 27 April 2017|Alad}}<br />
<br />
::There's a gradm ABI version included in the version, but it doesn't have the importance that they think it does. The grsecurity version is the kernel version + the grsecurity timestamp. That 3.1 version is only relevant to RBAC / gradm, and RBAC certainly has a lot of improvements without that version changing since I think it's only for breaking changes to the ABI. -- [[User:thestinger|thestinger]] 16:22, 29 April 2017 (UTC)<br />
<br />
:If things change and grsecurity is available in some form to Arch Linux users, I don't think it would be hard to resurrect the page (or parts of it) from the archive. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 23:33, 28 April 2017 (UTC)<br />
<br />
:There isn't going to be individual licensing. If someone takes over maintenance, it needs to be renamed from PaX and grsecurity so there will need to be a new name for this page and a bunch of configuration and tool naming may end up being updated to match the new name if it's a true fork with active development. Maintaining the 4.9 patch is a dead end and if that's all that happens, it's over. Either way, I'm not maintaining it anymore including paxd and the exceptions being a dead project. I saw this coming for a long time, so I haven't been putting much work into it for a while and now it's over. The most I'll consider is a package enabling the Kernel Self Protection Project features... which is such a tiny portion of what was provided. Key features like RAP are going to be unavailable for 5+ years if they even land at all. -- [[User:thestinger|thestinger]] 16:17, 29 April 2017 (UTC)<br />
<br />
<br />
== Kernel hardening - disabling jit compiler ==<br />
<br />
Currently, this page advises to disable bpf jit compiler by setting ''net.core.bpf_jit_enable'' to 0. Doing so causes error:<br />
<pre><br />
$ sudo sysctl -w net.core.bpf_jit_enable=0 <br />
sysctl: setting key "net.core.bpf_jit_enable": Invalid argument<br />
net.core.bpf_jit_enable = 0<br />
</pre><br />
This commit in the linux repo from January seems to indicate that disabling the jit compiler is not longer possible (or desirable): [https://github.com/torvalds/linux/commit/290af86629b25ffd1ed6232c4e9107da031705cb commit on Github torvalds/linux]. There is however a ''net.core.bpf_jit_harden'' flag available. I do not have the necessary knowledge to decide on what the best course of action is and edit the pages. Should the ''Keep BPF JIT compiler disabled'' section be removed? Is the''bpf_jit_harden'' flag advisable? [[User:Gthau|Gthau]] ([[User talk:Gthau|talk]]) 18:34, 26 March 2018 (UTC)<br />
<br />
== Password maintenance ==<br />
<br />
Regarding [[Special:Diff/524512]].<br />
<br />
I don't see why periodically changing the master password would improve anything.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:35, 1 July 2018 (UTC)<br />
<br />
:I agree. If the password is cryptographically secure and no one else has access to it, it would be best to leave it unchanged. <br />
<br />
:--[[User:phil.r.dubois|phil.r.dubois]] ([[User talk:phil.r.dubois|talk]]) 19:01, 1 July 2018 (UTC)</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Android&diff=525892Android2018-06-13T01:07:36Z<p>Phil.r.dubois: /* Odin (Virtualbox) */ grammar</p>
<hr />
<div>[[Category:Android]]<br />
[[Category:Development]]<br />
[[es:Android]]<br />
[[it:Android]]<br />
[[ja:Android]]<br />
[[ru:Android]]<br />
[[zh-hans:Android]]<br />
{{Related articles start}}<br />
{{Related|Android tethering}}<br />
{{Related|Android Debug Bridge}}<br />
{{Related articles end}}<br />
== Transferring files ==<br />
<br />
To transfer files between your computer and an Android device via USB you can use:<br />
<br />
* [[Media Transfer Protocol]] for modern Android devices<br />
* [https://www.howtogeek.com/192732/android-usb-connections-explained-mtp-ptp-and-usb-mass-storage/ USB Mass Storage mode] for older devices<br />
* the [[Android Debug Bridge]]<br />
<br />
Otherwise files can be transferred with various protocols ([[SSH]], [[:Category:File Transfer Protocol|FTP]], [[Samba]], HTTP). You just need to setup a client and a server (via apps Android can act as either one).<br />
<br />
File sharing apps which have a Linux counterpart are:<br />
<br />
* [[KDE Connect]] ({{Pkg|kdeconnect}}) – integrates your Android device with the KDE desktop (featuring synced notifications & clipboard, multimedia control, and file/URL sharing).<br />
* {{AUR|sendanywhere}} – cross-platform file sharing<br />
<br />
== App development ==<br />
<br />
The officially supported way to build Android apps is to use [[#Android Studio]].[https://developer.android.com/training/basics/firstapp/creating-project]<br />
<br />
=== Android Studio ===<br />
<br />
[https://developer.android.com/studio/index.html Android Studio] is the official Android development environment based on [[Wikipedia:IntelliJ IDEA|IntelliJ IDEA]]. It provides integrated Android developer tools for development and debugging.<br />
<br />
You can [[install]] it with the {{AUR|android-studio}} package.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* Make sure you properly [[Java#Change_default_Java_environment|set the Java environment]] otherwise android-studio will not start.<br />
* If Android Studio shows up as a blank window try [[export]]ing {{ic|1=_JAVA_AWT_WM_NONREPARENTING=1}}, see [https://code.google.com/p/android/issues/detail?id=57675 issue #57675].<br />
}}<br />
<br />
The Android Studio Setup Wizard installs the required [[#SDK packages]] for you and and places the SDK by default in {{ic|~/Android/Sdk}}.<br />
<br />
To build apps from the command-line (using e.g. {{ic|./gradlew assembleDebug}}) set the [https://developer.android.com/studio/command-line/variables#android_sdk_root ANDROID_SDK_ROOT] [[environment variable]] to your SDK location.<br />
<br />
=== SDK packages ===<br />
<br />
Android SDK packages can be installed directly from upstream using [[#Android Studio]]'s [https://developer.android.com/studio/intro/update#sdk-manager SDK Manager] or the [https://developer.android.com/studio/command-line/sdkmanager sdkmanager] command line tool (part of the Android SDK Tools). Some Android SDK packages are also available as [[AUR]] packages, they generally install to {{ic|/opt/android-sdk/}}.<br />
<br />
The [https://developer.android.com/studio/intro/update#recommended required SDK packages] are:<br />
<br />
{| class="wikitable"<br />
! Android SDK Package !! SDK-style path !! AUR package !! AUR dummy !! CLI tools<br />
|-<br />
| [https://developer.android.com/studio/releases/sdk-tools SDK Tools] || tools || {{AUR|android-sdk}} || {{AUR|android-sdk-dummy}} || sdkmanager, apkanalizer, avdmanager, mksdcard, proguard<br />
|-<br />
| [https://developer.android.com/studio/releases/build-tools SDK Build-Tools] || build-tools;''version'' || {{AUR|android-sdk-build-tools}} || {{AUR|android-sdk-build-tools-dummy}} || apksigner, zipalign<br />
|-<br />
| [https://developer.android.com/studio/releases/platform-tools SDK Platform-Tools] || platform-tools || {{AUR|android-sdk-platform-tools}} || {{AUR|android-sdk-platform-tools-dummy}} || [[adb]], [[#Fastboot|#fastboot]] and systrace<br />
|-<br />
| [https://developer.android.com/studio/releases/platforms SDK Platform] || platforms;android-''level'' || {{AUR|android-platform}}, [https://aur.archlinux.org/packages/?K=android-platform- older versions] || unnecessary<br />
|}<br />
<br />
The {{Pkg|android-tools}} package provides [[adb]], [[#Fastboot|#fastboot]], {{ic|e2fsdroid}} and {{ic|mke2fs.android}} from the SDK Platform-Tools along with {{ic|mkbootimg}} and {{ic|ext2simg}}.<br />
<br />
{{Note|1=&nbsp;<br />
* Since the Android SDK contains 32-bit binaries, you must enable the [[multilib]] repository. Otherwise you will get {{ic|error: target not found: lib32-*}} error messages.<br />
* If you choose to directly install SDK packages from upstream, install the AUR packages of the ''AUR dummy'' column to pull in the required dependencies.}}<br />
<br />
==== Android Emulator ====<br />
<br />
The [https://developer.android.com/studio/run/emulator Android Emulator] is available as the {{ic|emulator}} SDK package, the {{AUR|android-emulator}} package. And there's also a dummy package for it: {{AUR|android-emulator-dummy}}.<br />
<br />
To run the Android Emulator you need an Intel or ARM System Image. You can install them through the AUR[https://aur.archlinux.org/packages/?K=android-+system+image], with the sdkmanager or using Android Studio's [https://developer.android.com/studio/run/managing-avds AVD Manager].<br />
<br />
==== Other SDK packages in the AUR ====<br />
<br />
The [https://developer.android.com/topic/libraries/support-library/ Android Support Library] is now available online from [https://developer.android.com/studio/build/dependencies#google-maven Google's Maven repository].<br />
You can also install it offline through the {{ic|extras;android;m2repository}} SDK package (also available as {{AUR|android-support-repository}}).<br />
<br />
==== Making /opt/android-sdk group-owned ====<br />
<br />
The AUR packages install the SDK in {{ic|/opt/android-sdk/}}. This directory has root [[permissions]], so keep in mind to run sdk manager as root, otherwise you will not be able to modify anything in this directory. If you intend to use it as a regular user, create the Android sdk users group:<br />
<br />
# groupadd sdkusers<br />
<br />
Add your user into this group:<br />
<br />
# gpasswd -a <user> sdkusers<br />
<br />
Change folder's group.<br />
<br />
# chown -R :sdkusers /opt/android-sdk/<br />
<br />
Change permissions of the folder so the user that was just added to the group will be able to write in it:<br />
<br />
# chmod -R g+w /opt/android-sdk/<br />
<br />
Re-login or as <user> log your terminal in to the newly created group:<br />
<br />
$ newgrp sdkusers<br />
<br />
=== Other IDEs ===<br />
<br />
Android Studio is the official Android development environment based on IntelliJ IDEA. Alternatively, you can use [[Netbeans]] with the NBAndroid plugin. All are described below.<br />
<br />
==== Netbeans ====<br />
<br />
If you prefer using [[Netbeans]] as your IDE and want to develop Android applications, download the [http://www.nbandroid.org NBAndroid] by going to ''Tools > Plugins > Settings''.<br />
<br />
Add the following URL: http://nbandroid.org/release81/updates/updates.xml<br />
<br />
Then go to ''Available Plugins'' and install the ''Android'' and ''JUnit'' plugins. Once you have installed go to ''Tools > Options > Miscellaneous > Android''.<br />
<br />
and select the path where the SDK is installed ({{ic|/opt/android-sdk}} by default). That is it, now you can create a new Android project and start developing using Netbeans.<br />
<br />
==== Eclipse ====<br />
<br />
{{Note|The Eclipse ADT plugin is no longer supported. Google recommends to use Android Studio instead.[https://android-developers.googleblog.com/2016/11/support-ended-for-eclipse-android.html]}}<br />
<br />
The official, but deprecated, [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT] plugin can be installed with the {{AUR|eclipse-android}} package.<br />
<br />
{{Note|<br />
* if you get a message about unresolvable dependencies, install [[Java]] manually and try again.<br />
* as an alternative, you can install the ADT via eclipse's built in "add new software" command (see instructions on ADT site).<br />
* if you are in real trouble, it is also possible to download Android SDK and use the bundled Eclipse. This usually works without problems.<br />
* if you need to install extra SDK plugins not found in the AUR, you must change the file ownership of /opt/android-sdk first. You can do this with {{ic|# chgrp -R users /opt/android-sdk ; chmod -R 0775 /opt/android-sdk}} (see [[File Permissions]] for more details).<br />
}}<br />
<br />
Enter the path to the Android SDK Location in ''Windows > Preferences > Android''.<br />
<br />
{{Note|If the plugins do not show up in Eclipse after the AUR package has been upgraded, then eclipse probably has out-of-date caches. Running {{ic|sudo eclipse -clean}} once should clear them. If the problem persists, uninstall eclipse and all the plugins, delete {{ic|/usr/share/eclipse}}, and reinstall everything.}}<br />
<br />
== Building ==<br />
<br />
Please note that these instructions are based on the [https://source.android.com/source/building official AOSP build instructions]. Other Android-derived systems such as LineageOS will often require extra steps.<br />
<br />
=== Required packages ===<br />
<br />
To build any version of Android, you need to install these packages:<br />
<br />
* {{Pkg|lib32-gcc-libs}} {{Pkg|git}} {{Pkg|gnupg}} {{Pkg|flex}} {{Pkg|bison}} {{Pkg|gperf}} {{Pkg|sdl}} {{Pkg|wxgtk2}} {{Pkg|squashfs-tools}} {{Pkg|curl}} {{Pkg|ncurses}} {{Pkg|zlib}} {{Pkg|schedtool}} {{Pkg|perl-switch}} {{Pkg|zip}} {{Pkg|unzip}} {{Pkg|libxslt}} {{Pkg|python2-virtualenv}} {{Pkg|bc}} {{Pkg|rsync}} {{Aur|ncurses5-compat-libs}} {{Pkg|lib32-zlib}} {{Pkg|lib32-ncurses}} {{Pkg|lib32-readline}} {{Aur|lib32-ncurses5-compat-libs}}<br />
<br />
The {{Aur|aosp-devel}} metapackage provides them all for simple installation.<br />
<br />
Additionally, LineageOS requires the following packages: {{AUR|xml2}}, {{Pkg|lzop}}, {{Pkg|pngcrush}}, {{Pkg|imagemagick}}<br />
<br />
They can be installed with the {{Aur|lineageos-devel}} metapackage.<br />
<br />
{{Accuracy|The note below is not clear and probably incomplete.}}<br />
{{Note|1=Installing both {{Pkg|maven}} and {{Pkg|gradle}} to build LineageOS may result in a build speed improvement as the build process will prefer the system's }}<br />
<br />
=== Java Development Kit ===<br />
<br />
The [https://source.android.com/source/requirements required JDK version] depends on the Android version you are building:<br />
<br />
* For Android 7 and 8 (Nougat and Oreo), OpenJDK 8 is required, which is available with the {{Pkg|jdk8-openjdk}} package. <br />
* For Android 5 and 6 (Lollipop and Marshmallow), OpenJDK 7 is required, which is available with the {{Pkg|jdk7-openjdk}} package.<br />
<br />
Older versions require a working '''Oracle JDK''' installed on your build system. It '''will not''' work with OpenJDK.<br />
<br />
* For Gingerbread through KitKat (2.3 - 4.4), Java 6 is required, which is available as {{AUR|jdk6}} from the AUR.<br />
* For Cupcake through Froyo (1.5 - 2.2), Java 5 is required, which is available as {{AUR|jdk5}} from the AUR.<br />
<br />
{{Note|1=<br />
Android expects Java in {{ic|/usr/lib/jvm/java-''version''-openjdk-amd64}}.<br />
Set JAVA_HOME to avoid this requirement and match the Arch Linux installation path.<br />
Example:<br />
<br />
$ export JAVA_HOME=/usr/lib/jvm/java-''version''-openjdk<br />
<br />
This change will be valid only for the current terminal session.<br />
}}<br />
<br />
=== Setting up the build environment ===<br />
<br />
[[Install]] the {{Pkg|repo}} package. <br />
<br />
Create a directory to build.<br />
<br />
$ mkdir ~/android<br />
$ cd ~/android<br />
<br />
The Android build process expects {{ic|python}} to be python2. Create a python2 virtual environment and activate it:<br />
<br />
$ virtualenv2 venv<br />
$ source venv/bin/activate<br />
<br />
{{Note|<br />
* This activation is only active for the current terminal session. The virtual env will be kept in the {{ic|venv}} folder.<br />
* During build you may receive error pertaining to missing python modules. A quick and dirty fix is to symlink /usr/lib/python2.7/* to ~/android/venv/lib/python2.7/ (Change ~/android to reflect your build directory if different than above).<br />
Example:<br />
<br />
$ ln -s /usr/lib/python2.7/* ~/android/venv/lib/python2.7/<br />
<br />
or (assuming build directory Data/Android_Build):<br />
<br />
$ ln -s /usr/lib/python2.7/* /Data/Android_Build/venv/lib/python2.7/<br />
<br />
}}<br />
<br />
=== Downloading the source code ===<br />
<br />
This will clone the repositories. You '''only''' need to do this the first time you build Android, or if you want to switch branches.<br />
<br />
* The {{ic|repo}} has a {{ic|-j}} switch that operates similarly to the one used with {{ic|make}}. Since it controls the number of simultaneous downloads, you should adjust the value depending on downstream network bandwidth.<br />
<br />
* You will need to specify a '''branch''' (release of Android) to check out with the {{ic|-b}} switch. If you leave the switch out, you will get the so-called '''master branch'''.<br />
<br />
<pre><br />
$ repo init -u https://android.googlesource.com/platform/manifest -b master<br />
$ repo sync -j4<br />
</pre><br />
<br />
{{Note|To further decrease sync times, you can utilize the -c switch with the repo command as such:<br />
<br />
$ repo sync -j8 -c<br />
<br />
The {{ic|-c}} switch will only sync the branch which is specified in the manifest, which in turn is determined by the branch specified with the {{ic|-b}} switch, or the default branch set by the repository maintainer.<br />
}}<br />
<br />
Wait a long time. Just the uncompiled source code, along with the {{ic|.repo}} and {{ic|.git}} directories that are used to keep track of it, are well over 10 GB. As of Android 6.0.1, the entire codebase totals 40 GB.<br />
<br />
{{Note|If you want to update your local copy of the Android source, at a later time, simply enter the build directory, load the Virtualenv, and re-sync:<br />
<br />
$ repo sync<br />
<br />
}}<br />
<br />
=== Building the code ===<br />
<br />
This should do what you need for AOSP:<br />
<br />
$ source build/envsetup.sh<br />
$ lunch full-eng<br />
$ make -j4<br />
<br />
If you run '''lunch''' without arguments, it will ask what build you want to create. Use -j with a number between one and two times number of cores/threads.<br />
<br />
The build takes a very long time.<br />
<br />
{{Note|<br />
* Make sure you have enough RAM. Android will use the {{ic|/tmp}} directory heavily. By default the size of the partition the {{ic|/tmp}} folder is mounted on is half the size of your RAM. If it fills up, the build will fail. 4GB of RAM or more is recommended. Alternatively, you can get rid of the tmpfs from [[fstab]] all together.<br />
* From the [https://source.android.com/source/building#build-the-code Android Building and Running guide]:<br />
"GNU make can handle parallel tasks with a {{ic|-jN}} argument, and it's common to use a number of tasks N that's between 1 and 2 times the number of hardware threads on the computer being used for the build. E.g. on a dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core), the fastest builds are made with commands between {{ic|make -j16}} and {{ic|make -j32}}."<br />
}}<br />
<br />
=== Testing the build ===<br />
<br />
When finished, run/test the final image(s).<br />
<br />
$ emulator<br />
<br />
=== Creating a flashable Image ===<br />
<br />
To create an image that can be flashed it is necessary to:<br />
<br />
make -j8 updatepackage<br />
<br />
This will create a zip image under {{ic|'''out/target/product/hammerhead'''}} (hammerhead being the device name) that can be flashed.<br />
<br />
== Flashing ==<br />
<br />
In some cases, you want to return to the stock Android after flashing custom ROMs to your Android mobile device. For flashing instructions of your device, please use [http://forum.xda-developers.com/ XDA forums].<br />
<br />
=== Fastboot ===<br />
<br />
Fastboot (as well as [[ADB]]) is included in the {{Pkg|android-tools}} package.<br />
<br />
{{Note|Restoring firmwares using {{ic|fastboot}} can be quite tricky, but you might want to browse [http://www.xda-developers.com/ XDA developers forums] for a stock firmware, which is mostly a {{ic|*.zip}} file, but inside of it, comes with the firmware files and {{ic|flash-all.sh}} script. For example, [https://developers.google.com/android/nexus/images Google Nexus] firmwares include {{ic|flash-all.sh}} script or another example could be for OnePlus One - [http://forum.xda-developers.com/oneplus-one/general/guide-return-opo-to-100-stock-t2826541 XDA thread], where you can find firmwares with included {{ic|flash-all.sh}} script.}}<br />
<br />
=== Samsung devices ===<br />
<br />
Samsung devices can't be flashed using '''Fastboot''' tool. Alternatives are only '''Heimdall''' and '''Odin''' (by using Windows and VirtualBox).<br />
<br />
==== Heimdall ====<br />
<br />
[http://glassechidna.com.au/heimdall/ Heimdall] is a cross-platform open-source tool suite used to flash firmware (also known as ROMs) onto Samsung mobile devices and is also known as an alternative to [http://odindownload.com/ Odin]. It can be installed as {{AUR|heimdall}}.<br />
<br />
The flashing instructions can be found on Heimdall's [https://github.com/Benjamin-Dobell/Heimdall/tree/master/Linux GitHub page] or on [http://forum.xda-developers.com/showthread.php?t=1922461 XDA forums].<br />
<br />
==== Odin (Virtualbox) ====<br />
<br />
{{Note|1=This section only covers preparation and '''not''' flashing instructions. Search [http://www.xda-developers.com XDA developers forums] to find flashing instructions for a specific device. For example, [https://forum.xda-developers.com/showthread.php?t=2265477 Samsung Galaxy S4].}}<br />
<br />
It is also possible to restore [http://www.sammobile.com/firmwares/ firmware (Android)] on the Samsung devices using [http://odindownload.com/ Odin], but inside the [[VirtualBox]].<br />
<br />
Arch Linux (host) preparation:<br />
<br />
# Install [[VirtualBox]] together with its [[VirtualBox#Extension_pack|extension pack]] and [[VirtualBox#Guest_additions_disc|guest additions]].<br />
# Install your preferred, but compatible with Odin, Windows operating system (with VirtualBox guest additions) into a virtual hard drive using VirtualBox.<br />
# Open VirtualBox settings of your Windows operating system, navigate to ''USB'', then tick (or make sure it is ticked) '''Enable USB 2.0 (EHCI) Controller'''.<br />
# At VirtualBox running Windows operating system, click in the menu bar ''Devices > USB Devices'', then click on your Samsung mobile device from the list, which is connected to your computer via USB.<br />
<br />
Windows (guest) preparation:<br />
<br />
# Install [http://androidxda.com/download-samsung-usb-drivers Samsung drivers].<br />
# Install [http://odindownload.com/ Odin].<br />
# Download required [http://www.sammobile.com/firmwares/ Samsung firmware (Android)] for your smartphone model.<br />
<br />
Check if configuration is working:<br />
<br />
# Turn your device into Download mode and connect to your Linux machine.<br />
# In virtual machine toolbar, select ''Devices > USB > ...Samsung...'' device.<br />
# Open Odin. The white box (a big one at the bottom-left side) named '''Message''', should print a line similar to this:<br />
<br />
<ID:0/003> Added!!<br />
<br />
which means that your device is visible to Odin & Windows operating system and is ready to be flashed.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Android Studio: Android Virtual Devices show 'failed to load'. ===<br />
<br />
Make sure you've exported the variable {{ic|ANDROID_HOME}} as explained in [[#Android Studio]].<br />
<br />
=== Android Studio: 'failed to create the SD card' ===<br />
<br />
If you try to run an AVD (Android Virtual Device) under x86_64 Arch and get the error above, install the {{Pkg|lib32-gcc-libs}} package from the [[Multilib]] repository.<br />
<br />
=== Eclipse: During Debugging "Source not found" ===<br />
<br />
Most probably the debugger wants to step into the Java code. As the source code of Android does not come with the Android SDK, this leads to an error. The best solution is to use step filters to not jump into the Java source code. Step filters are not activated by default. To activate them: ''Window > Preferences > Java > Debug > Step Filtering''.<br />
Consider to select them all. If appropriate you can add the android.* package. See the forum post for more information: http://www.eclipsezone.com/eclipse/forums/t83338.rhtml<br />
<br />
=== ValueError: unsupported pickle protocol ===<br />
<br />
One fix is to issue:<br />
<br />
$ rm ~/.repopickle_.gitconfig<br />
<br />
If that does not work, then try this:<br />
<br />
$ find /path/to/android-root -name .repopickle_config -delete<br />
<br />
=== libGL error: failed to load driver: swrast OR AVD doesn't load and no error message displayed ===<br />
<br />
Sometimes, beginning to load an AVD will cause an error message similar to this to be displayed, or the loading process will appear to finish but no AVD will load and no error message will be displayed.<br />
<br />
The AVD loads an incorrect version of libstdc++, you can remove the folder libstdc++ from {{ic|~/.android-sdk/emulator/lib64}} (for 64-bit) or {{ic|~/.android-sdk/emulator/lib}} (for 32-bit) , e.g.:<br />
<br />
$ rm -r ~/.android-sdk/emulator/lib64/libstdc++<br />
<br />
Note that in versions before Android Studio 3.0, this directory was in a different location:<br />
<br />
$ rm -r ~/Android/Sdk/emulator/lib64/libstdc++<br />
<br />
Alternatively you can set and export ANDROID_EMULATOR_USE_SYSTEM_LIBS in ~/.profile as:<br />
<br />
export ANDROID_EMULATOR_USE_SYSTEM_LIBS=1<br />
<br />
Reference: [https://developer.android.com/studio/command-line/variables.html#studio_jdk Android Studio user guide]<br />
<br />
Fix for the .desktop file might be achieved by using env command, prefixing the Exec line [[Desktop entries#Modify environment variables]]<br />
<br />
env ANDROID_EMULATOR_USE_SYSTEM_LIBS=1<br />
<br />
=== sh: glxinfo: command not found===<br />
<br />
Here's the full error:<br />
<br />
Cannot launch AVD in emulator.<br />
Output:<br />
sh: glxinfo: command not found<br />
sh: glxinfo: command not found<br />
libGL error: unable to load driver: swrast_dri.so<br />
libGL error: failed to load driver: swrast<br />
X Error of failed request: BadValue (integer parameter out of range for operation)<br />
Major opcode of failed request: 154 (GLX)<br />
Minor opcode of failed request: 24 (X_GLXCreateNewContext)<br />
Value in failed request: 0x0<br />
Serial number of failed request: 32<br />
Current serial number in output stream: 33<br />
QObject::~QObject: Timers cannot be stopped from another thread<br />
<br />
You can try to install glxinfo ({{Pkg|mesa-demos}}) but if your computer has enough power you could simply use software to render graphics. To do so, go to ''Tools > Android > AVD Manager'', edit the ''AVD'' (click the pencil icon), then select ''Software - GLES 2.0'' for ''Emulated Performance > Graphics''.<br />
<br />
=== Android Emulator: no keyboard input in xfwm4 ===<br />
<br />
In xfwm4, the vertical toolbar buttons window that is on the right of the emulator takes focus from the emulator and consumes keyboard events.<br />
([https://issuetracker.google.com/issues/37094173 bug report])<br />
<br />
You can use the workaround described in [https://stackoverflow.com/a/42720450/1366471 this Stack Overflow answer]:<br />
<br />
# Open the xfwm4 settings.<br />
# Switch to the Focus tab.<br />
# Change the Focus Model to "Focus follow mouse".<br />
# Disable ''Automatically raise windows when they receive focus'' option below.</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=LVM&diff=518350LVM2018-04-23T05:08:15Z<p>Phil.r.dubois: /* Configuration */ emphasized that the snapshot will cease to exist after merging</p>
<hr />
<div>[[Category:Storage virtualization]]<br />
[[cs:LVM]]<br />
[[de:LVM]]<br />
[[es:LVM]]<br />
[[fr:LVM]]<br />
[[it:LVM]]<br />
[[ja:LVM]]<br />
[[ru:LVM]]<br />
[[zh-hans:LVM]]<br />
{{Related articles start}}<br />
{{Related|Software RAID and LVM}}<br />
{{Related|dm-crypt/Encrypting an entire system#LVM on LUKS}}<br />
{{Related|dm-crypt/Encrypting an entire system#LUKS on LVM}}<br />
{{Related|Resizing LVM-on-LUKS}}<br />
{{Related|Create root filesystem snapshots with LVM}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Logical Volume Manager (Linux)]]:<br />
:LVM is a [[Wikipedia:logical volume management|logical volume manager]] for the [[Wikipedia:Linux kernel|Linux kernel]]; it manages disk drives and similar mass-storage devices.<br />
<br />
== LVM Building Blocks ==<br />
<br />
Logical Volume Management utilizes the kernel's [http://sources.redhat.com/dm/ device-mapper] feature to provide a system of partitions independent of underlying disk layout. With LVM you abstract your storage and have "virtual partitions", making [[#Resizing volumes|extending/shrinking]] easier (subject to potential filesystem limitations).<br />
<br />
Virtual partitions allow addition and removal without worry of whether you have enough contiguous space on a particular disk, getting caught up fdisking a disk in use (and wondering whether the kernel is using the old or new partition table), or, having to move other partitions out of the way. This is strictly an ease-of-management solution: LVM adds no security.<br />
<br />
Basic building blocks of LVM:<br />
<br />
; Physical volume (PV): Partition on hard disk (or even the disk itself or loopback file) on which you can have volume groups. It has a special header and is divided into physical extents. Think of physical volumes as big building blocks used to build your hard drive.<br />
; Volume group (VG): Group of physical volumes used as a storage volume (as one disk). They contain logical volumes. Think of volume groups as hard drives.<br />
; Logical volume (LV): A "virtual/logical partition" that resides in a volume group and is composed of physical extents. Think of logical volumes as normal partitions.<br />
; Physical extent (PE): The smallest size in the physical volume that can be assigned to a logical volume (default 4 MiB). Think of physical extents as parts of disks that can be allocated to any partition.<br />
<br />
Example:<br />
'''Physical disks'''<br />
<br />
Disk1 (/dev/sda):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 50 GiB (Physical volume) |Partition2 80 GiB (Physical volume) |<br />
|/dev/sda1 |/dev/sda2 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |<br />
<br />
Disk2 (/dev/sdb):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 120 GiB (Physical volume) |<br />
|/dev/sdb1 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
<br />
'''LVM logical volumes'''<br />
<br />
Volume Group1 (/dev/MyStorage/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Logical volume1 15 GiB |Logical volume2 35 GiB |Logical volume3 200 GiB |<br />
|/dev/MyStorage/rootvol |/dev/MyStorage/homevol |/dev/MyStorage/mediavol |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
<br />
== Advantages ==<br />
<br />
LVM gives you more flexibility than just using normal hard drive partitions:<br />
<br />
* Use any number of disks as one big disk.<br />
* Have logical volumes stretched over several disks.<br />
* Create small logical volumes and resize them "dynamically" as they get filled up.<br />
* Resize logical volumes regardless of their order on disk. It does not depend on the position of the LV within VG, there is no need to ensure surrounding available space.<br />
* Resize/create/delete logical and physical volumes online. File systems on them still need to be resized, but some (such as ext4) support online resizing.<br />
* Online/live migration of LV being used by services to different disks without having to restart services.<br />
* Snapshots allow you to backup a frozen copy of the file system, while keeping service downtime to a minimum.<br />
* Support for various device-mapper targets, including transparent filesystem encryption and caching of frequently used data. This allows creating a system with (one or more) physical disks (encrypted with LUKS) and [[dm-crypt/Encrypting an entire system#LVM on LUKS|LVM on top]] to allow for easy resizing and management of separate volumes (e.g. for {{ic|/}}, {{ic|/home}}, {{ic|/backup}}, etc.) without the hassle of entering a key multiple times on boot.<br />
<br />
== Disadvantages ==<br />
<br />
* Additional steps in setting up the system, more complicated.<br />
* If dual-booting, note that Windows does not support LVM; you will be unable to access any LVM partitions from Windows.<br />
<br />
== Installing Arch Linux on LVM ==<br />
<br />
You should create your LVM Volumes between the [[partitioning]] and [[File systems#Create a file system|formatting]] steps of the [[Installation guide|installation procedure]]. Instead of directly formatting a partition to be your root file system, the file system will be created inside a logical volume (LV). <br />
<br />
Make sure the {{pkg|lvm2}} package is [[installed]].<br />
<br />
Quick overview: <br />
<br />
* Create [[Partitioning|partition(s)]] where your PV(s) will reside.<br />
** If you use Master Boot Record partition table, set the [[Wikipedia:Partition type|partition type ID]] to {{ic|8e}} (partition type {{ic|Linux LVM}} in ''fdisk'').<br />
** If you use GUID Partition Table, set the [[Wikipedia:GUID Partition Table#Partition type GUIDs|partition type GUID]] to {{ic|E6D6D379-F507-44C2-A23C-238F2A3DF928}} (partition type {{ic|Linux LVM}} in ''fdisk'' and {{ic|8e00}} in ''gdisk'').<br />
* Create your physical volumes (PVs). If you have one disk it is best to just create one PV in one large partition. If you have multiple disks you can create partitions on each of them and create a PV on each partition.<br />
* Create your volume group (VG) and add all PVs to it.<br />
* Create logical volumes (LVs) inside that VG.<br />
* Continue with [[Installation guide#Format the partitions]].<br />
* When you reach the “Create initial ramdisk environment” step in the Installation guide, add the {{ic|lvm}} hook to {{ic|/etc/mkinitcpio.conf}} (see below for details).<br />
<br />
{{Warning|{{ic|/boot}} cannot reside in LVM when using a boot loader which does not support LVM; you must create a separate {{ic|/boot}} partition and format it directly. Only [[GRUB]] is known to support LVM.}}<br />
<br />
=== Create partitions ===<br />
<br />
If LVM has to be set on the entire disk, there is no need to create any partitions.<br />
<br />
Otherwise, [[partition]] the device as required before configuring LVM.<br />
<br />
=== Create physical volumes ===<br />
<br />
To list all your devices capable of being used as a physical volume:<br />
<br />
# lvmdiskscan<br />
<br />
{{Warning|Make sure you target the correct device, or below commands will result in data loss!}}<br />
<br />
Create a physical volume on them:<br />
<br />
# pvcreate ''DEVICE''<br />
<br />
This command creates a header on each device so it can be used for LVM. As defined in [[#LVM Building Blocks]], ''DEVICE'' can be a disk (e.g. {{ic|/dev/sda}}), a partition (e.g. {{ic|/dev/sda2}}) or a loop back device. For example: <br />
<br />
# pvcreate /dev/sda2<br />
<br />
You can track created physical volumes with:<br />
<br />
# pvdisplay<br />
<br />
{{Note|If using a SSD without partitioning it first, use {{ic|pvcreate --dataalignment 1m /dev/sda}} (for erase block size < 1 MiB), see e.g. [http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment here]}}<br />
<br />
=== Create volume group ===<br />
<br />
The next step is to create a volume group on this physical volume.<br />
<br />
First you need to create a volume group on one of the physical volumes:<br />
<br />
# vgcreate <''volume_group''> <''physical_volume''><br />
<br />
See {{man|8|lvm}} for a list of valid characters for volume group names.<br />
<br />
For example:<br />
<br />
# vgcreate VolGroup00 /dev/sda2<br />
<br />
Then add to it all other physical volumes you want to have in it:<br />
<br />
# vgextend <''volume_group''> <''physical_volume''><br />
# vgextend <''volume_group''> <''another_physical_volume''><br />
# ...<br />
<br />
For example:<br />
<br />
# vgextend VolGroup00 /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdc<br />
<br />
You can track how your volume group grows with:<br />
<br />
# vgdisplay<br />
<br />
{{Note|You can create more than one volume group if you need to, but then you will not have all your storage presented as one disk.}}<br />
<br />
=== Create in one step ===<br />
<br />
LVM allows you to combine the creation of a volume group and the physical volumes in one easy step. For example, to create the group VolGroup00 with the three devices mentioned above, you can run:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb1 /dev/sdc<br />
<br />
This command will first set up the three partitions as physical volumes (if necessary) and then create the volume group with the three volumes. The command will warn you it detects an existing filesystem on any of the devices.<br />
<br />
=== Create logical volumes ===<br />
<br />
{{Tip|If you wish to use snapshots, logical volume caching, thin provisioned logical volumes or RAID see [[#Logical volume types]].}}<br />
<br />
Now we need to create logical volumes on this volume group. You create a logical volume with the next command by giving the name of a new logical volume, its size, and the volume group it will live on:<br />
<br />
# lvcreate -L <''size''> <''volume_group''> -n <''logical_volume''><br />
<br />
For example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome<br />
<br />
This will create a logical volume that you can access later with {{ic|/dev/mapper/Volgroup00-lvolhome}} or {{ic|/dev/VolGroup00/lvolhome}}. Just like volume groups, you can use any name you want for your logical volume when creating it besides a few exceptions listed in {{man|8|lvm|VALID_NAMES}}.<br />
<br />
You can also specify one or more physical volumes to restrict where LVM allocates the data. For example, you may wish to create a logical volume for the root filesystem on your small SSD, and your home volume on a slower mechanical drive. Simply add the physical volume devices to the command line, for example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome /dev/sdc1<br />
<br />
If you want to fill all the free space left on a volume group, use the next command:<br />
<br />
# lvcreate -l 100%FREE <''volume_group''> -n <''logical_volume''><br />
<br />
You can track created logical volumes with:<br />
<br />
# lvdisplay<br />
<br />
{{Note|You may need to load the ''device-mapper'' kernel module ({{ic|modprobe dm_mod'}}) for the above commands to succeed.}}<br />
<br />
{{Tip|You can start out with relatively small logical volumes and expand them later if needed. For simplicity, leave some free space in the volume group so there is room for expansion.}}<br />
<br />
=== Create file systems and mount logical volumes ===<br />
<br />
Your logical volumes should now be located in {{ic|/dev/mapper/}} and {{ic|/dev/''YourVolumeGroupName''}}. If you cannot find them, use the next commands to bring up the module for creating device nodes and to make volume groups available:<br />
<br />
# modprobe dm_mod<br />
# vgscan<br />
# vgchange -ay<br />
<br />
Now you can create file systems on logical volumes and mount them as normal partitions (if you are installing Arch linux, refer to [[mount|mounting the partitions]] for additional details):<br />
<br />
# mkfs.<''fstype''> /dev/mapper/<''volume_group''>-<''logical_volume''><br />
# mount /dev/mapper/<''volume_group''>-<''logical_volume''> /<''mountpoint''><br />
<br />
For example:<br />
<br />
# mkfs.ext4 /dev/mapper/VolGroup00-lvolhome<br />
# mount /dev/mapper/VolGroup00-lvolhome /home<br />
<br />
{{Warning|When choosing mountpoints, just select your newly created logical volumes (use: {{ic|/dev/mapper/Volgroup00-lvolhome}}). Do '''not''' select the actual partitions on which logical volumes were created (do not use: {{ic|/dev/sda2}}).}}<br />
<br />
=== Configure mkinitcpio ===<br />
<br />
In case your root filesystem is on LVM, you will need to enable the appropriate [[mkinitcpio]] hooks, otherwise your system might not boot. Enable:<br />
<br />
* {{ic|udev}} and {{ic|lvm2}} for the default busybox based initramfs<br />
* {{ic|systemd}} and {{ic|sd-lvm2}} for systemd based initramfs<br />
<br />
{{ic|udev}} is there by default. Edit the file and insert {{ic|lvm2}} between {{ic|block}} and {{ic|filesystems}} like so:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=<br />
HOOKS=(base '''udev''' ... block '''lvm2''' filesystems)<br />
}}<br />
<br />
For systemd based initramfs:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=<br />
HOOKS=(base '''systemd''' ... block '''sd-lvm2''' filesystems)<br />
}}<br />
<br />
Afterwards, you can continue in normal installation instructions with the [[mkinitcpio#Image creation and activation|create an initial ramdisk]] step.<br />
<br />
{{Tip|<br />
* The {{ic|lvm2}} and {{ic|sd-lvm2}} hooks are installed by {{pkg|lvm2}}, not {{pkg|mkinitcpio}}. If you are running ''mkinitcpio'' in an ''arch-chroot'' for a new installation, {{pkg|lvm2}} must be installed inside the ''arch-chroot'' for ''mkinitcpio'' to find the {{ic|lvm2}} or {{ic|sd-lvm2}} hook. If {{pkg|lvm2}} only exists outside the ''arch-chroot'', ''mkinitcpio'' will output {{ic|Error: Hook 'lvm2' cannot be found}}.<br />
* If your root filesystem is on LVM RAID see [[#Configure mkinitcpio for RAID]].<br />
}}<br />
<br />
=== Kernel options ===<br />
<br />
If the root file system resides in a logical volume, the {{ic|1=root=}} [[kernel parameter]] must be pointed to the mapped device, e.g {{ic|/dev/mapper/''vg-name''-''lv-name''}}.<br />
<br />
== Volume operations ==<br />
<br />
=== Advanced options ===<br />
<br />
If you need monitoring (needed for snapshots) you can enable lvmetad. <br />
For this set {{ic|1=use_lvmetad = 1}} in {{ic|/etc/lvm/lvm.conf}}.<br />
This is the default by now. <br />
<br />
You can restrict the volumes that are activated automatically by setting the {{ic|auto_activation_volume_list}} in {{ic|/etc/lvm/lvm.conf}}. If in doubt, leave this option commented out.<br />
<br />
=== Resizing volumes ===<br />
<br />
==== Physical volumes ====<br />
<br />
After extending or prior to reducing the size of a device that has a physical volume on it, you need to grow or shrink the PV using {{ic|pvresize}}.<br />
<br />
===== Growing =====<br />
<br />
To expand the PV on {{ic|/dev/sda1}} after enlarging the [[partition]], run:<br />
<br />
# pvresize /dev/sda1<br />
<br />
This will automatically detect the new size of the device and extend the PV to its maximum.<br />
<br />
{{Note|This command can be done while the volume is online.}}<br />
<br />
===== Shrinking =====<br />
<br />
To shrink a physical volume prior to reducing its underlying device, add the {{ic|--setphysicalvolumesize ''size''}} parameters to the command, ''e.g.'':<br />
<br />
# pvresize --setphysicalvolumesize 40G /dev/sda1<br />
<br />
The above command may leave you with this error:<br />
<br />
/dev/sda1: cannot resize to 25599 extents as later ones are allocated.<br />
0 physical volume(s) resized / 1 physical volume(s) not resized<br />
<br />
Indeed {{ic|pvresize}} will refuse to shrink a PV if it has allocated extents after where its new end would be. One needs to run [[#Move physical extents|pvmove]] beforehand to relocate these elsewhere in the volume group if there is sufficient free space.<br />
<br />
====== Move physical extents ======<br />
<br />
Before moving free extents to the end of the volume, one must run {{ic|pvdisplay -v -m}} to see physical segments. In the below example, there is one physical volume on {{ic|/dev/sdd1}}, one volume group {{ic|vg1}} and one logical volume {{ic|backup}}.<br />
<br />
{{hc|# pvdisplay -v -m|<br />
Finding all volume groups.<br />
Using physical volume(s) on command line.<br />
--- Physical volume ---<br />
PV Name /dev/sdd1<br />
VG Name vg1<br />
PV Size 1.52 TiB / not usable 1.97 MiB<br />
Allocatable yes <br />
PE Size 4.00 MiB<br />
Total PE 399669<br />
Free PE 153600<br />
Allocated PE 246069<br />
PV UUID MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW<br />
<br />
--- Physical Segments ---<br />
Physical extent 0 to 153600:<br />
FREE<br />
Physical extent 153601 to 307199:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 1 to 153599<br />
Physical extent 307200 to 307200:<br />
FREE<br />
Physical extent 307201 to 399668:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 153601 to 246068<br />
}}<br />
<br />
One can observe FREE space are split across the volume. To shrink the physical volume, we must first move all used segments to the beginning.<br />
<br />
Here, the first free segment is from 0 to 153600 and leaves us with 153601 free extents. We can now move this segment number from the last physical extent to the first extent. The command will thus be:<br />
<br />
{{hc|# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92466|<br />
/dev/sdd1: Moved: 0.1 %<br />
/dev/sdd1: Moved: 0.2 %<br />
...<br />
/dev/sdd1: Moved: 99.9 %<br />
/dev/sdd1: Moved: 100,0%<br />
}}<br />
<br />
{{Note|<br />
* this command moves 92468 PEs (399668-307200) '''from''' the last segment '''to''' the first segment. This is possible as the first segment encloses 153600 free PEs, which can contain the 92467 moved PEs.<br />
* the {{ic|--alloc anywhere}} option is used as we move PEs inside the same partition. In case of different partitions, the command would look something like this: {{bc|# pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999}}<br />
* this command may take a long time (one to two hours) in case of large volumes. It might be a good idea to run this command in a [[Tmux]] or [[GNU Screen]] session. Any unwanted stop of the process could be fatal.<br />
* once the operation is complete, run [[fsck]] to make sure your file system is valid.<br />
}}<br />
<br />
====== Resize physical volume ======<br />
<br />
Once all your free physical segments are on the last physical extent, run {{ic|vgdisplay}} and see your free PE.<br />
<br />
Then you can now run again the command:<br />
<br />
# pvresize --setphysicalvolumesize ''size'' ''PhysicalVolume''<br />
<br />
See the result:<br />
<br />
{{hc|# pvs|<br />
PV VG Fmt Attr PSize PFree <br />
/dev/sdd1 vg1 lvm2 a-- 1t 500g<br />
}}<br />
<br />
====== Resize partition ======<br />
<br />
Last, you need to shrink the partition with your favorite [[Partitioning#Partitioning tools|partitioning tool]].<br />
<br />
==== Logical volumes ====<br />
<br />
{{Note|''lvresize'' provides more or less the same options as the specialized {{ic|lvextend}} and {{ic|lvreduce}} commands, while allowing to do both types of operation. Notwithstanding this, all those utilities offer a {{ic|-r}}/{{ic|--resizefs}} option which allows to resize the file system together with the LV using {{man|8|fsadm}} (''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] supported). Therefore it may be easier to simply use {{ic|lvresize}} for both operations and use {{ic|--resizefs}} to simplify things a bit, except if you have specific needs or want full control over the process.}}<br />
<br />
===== Growing or shrinking with lvresize =====<br />
<br />
{{Warning|While enlarging a file system can often be done on-line (''i.e.'' while it is mounted), even for the root partition, shrinking will nearly always require to first unmount the file system so as to prevent data loss. Make sure your FS supports what you are trying to do.}}<br />
<br />
Extend logical volume ''lv1'' within volume group ''vg1'' by 2 GiB ''without'' touching its file system:<br />
<br />
# lvresize -L +2G vg1/lv1<br />
<br />
Reduce the size of {{ic|vg1/lv1}} by 500 MiB ''without'' resizing its file system (make sure it is [[#Resizing the file system separately|already shrunk]] in that case):<br />
<br />
# lvresize -L -500M vg1/lv1<br />
<br />
Set {{ic|vg1/lv1}} to 15 GiB and resize its file system ''all at once'':<br />
<br />
# lvresize -L 15G -r vg1/lv1<br />
<br />
{{Note|Only ''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] [[file systems]] are supported. For a different type of file system look for the [[File systems#Types of file systems|appropriate utility]].}}<br />
<br />
If you want to fill all the free space on a volume group, use the following command:<br />
<br />
# lvresize -l +100%FREE ''vg''/''lv''<br />
<br />
See {{man|8|lvresize}} for more detailed options.<br />
<br />
===== Extending the logical volume and file system in one go =====<br />
<br />
{{Merge|#Growing or shrinking with lvresize|No need to split the sections.}}<br />
<br />
{{Warning|Not all file systems support resizing without loss of data and/or resizing online.}}<br />
<br />
Extend the logical volume ''home'' in ''volume-group'' with 10 GiB<br />
<br />
# lvresize -L +10G /dev/''volume-group''/''home'' --resizefs<br />
<br />
Alternatively with a XFS filesystem<br />
<br />
# lvextend -L+10G /dev/''volume-group''/''home''<br />
# xfs_growfs /home<br />
<br />
Note: ''xfs_growfs'' takes a mount point as argument. See {{man|8|xfs_growfs}} for more detailed options.<br />
<br />
===== Resizing the file system separately =====<br />
<br />
{{Move|Ext4|File system specific operations should be placed in their respective wiki pages.}}<br />
<br />
If not using the {{ic|-r}}/{{ic|--resizefs}} option to {{ic|lvresize}}, {{ic|lvextend}} or {{ic|lvreduce}}, or using a file system unsupported by {{man|8|fsadm}} (e.g. [[Btrfs]], [[ZFS]]), you need to manually resize the file system before shrinking the LV or after expanding it.<br />
<br />
{{Warning|Not all file systems support resizing without loss of data and/or resizing online.}}<br />
<br />
For example with an ext2/ext3/ext4 file system:<br />
<br />
# resize2fs ''vg''/''lv''<br />
<br />
will expand the FS to the maximum size of the underlying LV, while<br />
<br />
# resize2fs -M ''vg''/''lv''<br />
<br />
will shrink it to its minimum size. To resize it to a specified size, use:<br />
<br />
# resize2fs ''vg''/''lv'' ''NewSize''<br />
<br />
=== Remove logical volume ===<br />
<br />
{{Warning|Before you remove a logical volume, make sure to move all data that you want to keep somewhere else; otherwise, it will be lost!}}<br />
<br />
First, find out the name of the logical volume you want to remove. You can get a list of all logical volumes with:<br />
<br />
# lvs<br />
<br />
Next, look up the mountpoint of the chosen logical volume:<br />
<br />
$ lsblk<br />
<br />
Then unmount the filesystem on the logical volume:<br />
<br />
# umount /<''mountpoint''><br />
<br />
Finally, remove the logical volume:<br />
<br />
# lvremove <''volume_group''>/<''logical_volume''><br />
<br />
For example:<br />
<br />
# lvremove VolGroup00/lvolhome<br />
<br />
Confirm by typing in {{ic|y}}.<br />
<br />
Update {{ic|/etc/fstab}} as necessary.<br />
<br />
You can verify the removal of the logical volume by typing {{ic|lvs}} as root again (see first step of this section).<br />
<br />
=== Add physical volume to a volume group ===<br />
<br />
You first create a new physical volume on the block device you wish to use, then extend your volume group<br />
<br />
# pvcreate /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdb1<br />
<br />
This of course will increase the total number of physical extents on your volume group, which can be allocated by logical volumes as you see fit.<br />
<br />
{{Note|It is considered good form to have a [[Partitioning|partition table]] on your storage medium below LVM. Use the appropriate type code: {{ic|8e}} for MBR, and {{ic|8e00}} for GPT partitions.}}<br />
<br />
=== Remove partition from a volume group ===<br />
<br />
If you created a logical volume on the partition, [[#Remove logical volume|remove]] it first.<br />
<br />
All of the data on that partition needs to be moved to another partition. Fortunately, LVM makes this easy:<br />
<br />
# pvmove /dev/sdb1<br />
<br />
If you want to have the data on a specific physical volume, specify that as the second argument to {{ic|pvmove}}:<br />
<br />
# pvmove /dev/sdb1 /dev/sdf1<br />
<br />
Then the physical volume needs to be removed from the volume group:<br />
<br />
# vgreduce myVg /dev/sdb1<br />
<br />
Or remove all empty physical volumes:<br />
<br />
# vgreduce --all vg0<br />
<br />
And lastly, if you want to use the partition for something else, and want to avoid LVM thinking that the partition is a physical volume:<br />
<br />
# pvremove /dev/sdb1<br />
<br />
=== Deactivate volume group ===<br />
<br />
Just invoke <br />
<br />
# vgchange -a n my_volume_group<br />
<br />
This will deactivate the volume group and allow you to unmount the container it is stored in.<br />
<br />
== Logical volume types ==<br />
<br />
{{Expansion|Add instructions for thin-provisioned volume creation and RAID volume creation.|section=Logical volume types}}<br />
<br />
Besides simple logical volumes, LVM supports snapshots, logical volume caching, thin provisioned logical volumes and RAID.<br />
<br />
=== Snapshots ===<br />
<br />
LVM allows you to take a snapshot of your system in a much more efficient way than a traditional backup. It does this efficiently by using a COW (copy-on-write) policy. The initial snapshot you take simply contains hard-links to the inodes of your actual data. So long as your data remains unchanged, the snapshot merely contains its inode pointers and not the data itself. Whenever you modify a file or directory that the snapshot points to, LVM automatically clones the data, the old copy referenced by the snapshot, and the new copy referenced by your active system. Thus, you can snapshot a system with 35 GiB of data using just 2 GiB of free space so long as you modify less than 2 GiB (on both the original and snapshot). In order to be able to create snapshots you need to have unallocated space in your volume group. Snapshot like any other volume will take up space in the volume group. So, if you plan to use snapshots for backing up your root partition do not allocate 100% of your volume group for root logical volume.<br />
<br />
==== Configuration ====<br />
<br />
You create snapshot logical volumes just like normal ones.<br />
<br />
# lvcreate --size 100M --snapshot --name snap01 /dev/mapper/vg0-pv<br />
<br />
With that volume, you may modify less than 100 MiB of data, before the snapshot volume fills up.<br />
<br />
Reverting the modified 'pv' logical volume to the state when the 'snap01' snapshot was taken can be done with<br />
<br />
# lvconvert --merge /dev/mapper/vg0-snap01<br />
<br />
In case the origin logical volume is active, merging will occur on the next reboot (merging can be done even from a LiveCD). <br />
<br />
''The snapshot will no longer exist after merging.''<br />
<br />
Also multiple snapshots can be taken and each one can be merged with the origin logical volume at will.<br />
<br />
The snapshot can be mounted and backed up with '''dd''' or '''tar'''. The size of the backup file done with '''dd''' will be the size of the files residing on the snapshot volume. <br />
To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin.<br />
<br />
{{Expansion|scripts to automate snapshots of root before updates, to rollback... updating {{ic|menu.lst}} to boot snapshots (separate article?)}}<br />
<br />
Snapshots are primarily used to provide a frozen copy of a file system to make backups; a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.<br />
<br />
See [[Create root filesystem snapshots with LVM]] for automating the creation of clean root file system snapshots during system startup for backup and rollback.<br />
<br />
[[dm-crypt/Encrypting an entire system#LVM on LUKS]] and [[dm-crypt/Encrypting an entire system#LUKS on LVM]].<br />
<br />
If you have LVM volumes not activated via the [[initramfs]], [[enable]] {{ic|lvm-monitoring.service}}, which is provided by the {{pkg|lvm2}} package.<br />
<br />
=== LVM cache ===<br />
<br />
From {{man|7|lvmcache}}:<br />
<br />
: The cache logical volume type uses a small and fast LV to improve the performance of a large and slow LV. It does this by storing the frequently used blocks on the faster LV. LVM refers to the small fast LV as a cache pool LV. The large slow LV is called the origin LV. Due to requirements from dm-cache (the kernel driver), LVM further splits the cache pool LV into two devices - the cache data LV and cache metadata LV. The cache data LV is where copies of data blocks are kept from the origin LV to increase speed. The cache metadata LV holds the accounting information that specifies where data blocks are stored (e.g. on the origin LV or on the cache data LV). Users should be familiar with these LVs if they wish to create the best and most robust cached logical volumes. All of these associated LVs must be in the same VG.<br />
<br />
==== Create cache ====<br />
<br />
The fast method is creating a PV (if necessary) on the fast disk and add it to the existing volume group:<br />
<br />
# vgextend dataVG /dev/sdx<br />
<br />
Create a cache pool with automatic meta data on sdb, and convert the existing logical volume (dataLV) to a cached volume, all in one step:<br />
<br />
# lvcreate --type cache --cachemode writethrough -L 20G -n dataLV_cachepool dataVG/dataLV /dev/sdx<br />
<br />
Obviously, if you want your cache to be bigger, you can change the {{ic|-L}} parameter to a different size.<br />
<br />
{{Note|Cachemode has two possible options:<br />
* {{ic|writethrough}} ensures that any data written will be stored both in the cache pool LV and on the origin LV. The loss of a device associated with the cache pool LV in this case would not mean the loss of any data;<br />
* {{ic|writeback}} ensures better performance, but at the cost of a higher risk of data loss in case the drive used for cache fails.<br />
<br />
If a specific {{ic|--cachemode}} is not indicated, the system will assume {{ic|writethrough}} as default.<br />
}}<br />
<br />
==== Remove cache ====<br />
<br />
If you ever need to undo the one step creation operation above:<br />
<br />
# lvconvert --uncache dataVG/dataLV<br />
<br />
This commits any pending writes still in the cache back to the origin LV, then deletes the cache. Other options are available and described in {{man|7|lvmcache}}.<br />
<br />
=== RAID ===<br />
<br />
From {{man|7|lvmraid}}:<br />
: {{man|8|lvm}} RAID is a way to create a Logical Volume (LV) that uses multiple physical devices to improve performance or tolerate device failures. In LVM, the physical devices are Physical Volumes (PVs) in a single Volume Group (VG).<br />
<br />
LVM RAID supports RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 and RAID 10. See [[Wikipedia:Standard RAID levels]] for details on each level.<br />
<br />
==== Setup RAID ====<br />
<br />
Create physical volumes:<br />
<br />
# pvcreate /dev/sda2 /dev/sdb2<br />
<br />
Create volume group on the physical volumes:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb2<br />
<br />
Create logical volumes useing {{ic|lvcreate --type ''raidlevel''}}, see {{man|7|lvmraid}} and {{man|8|lvcreate}} for more options.<br />
<br />
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]<br />
<br />
For example:<br />
<br />
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol VolGroup00 /dev/sda2 /dev/sdb2<br />
<br />
will create a 20 GiB mirrored logical volume named "myraid1vol" in VolGroup00 on {{ic|/dev/sda2}} and {{ic|/dev/sdb2}}.<br />
<br />
==== Configure mkinitcpio for RAID ====<br />
<br />
If your root filesystem is on LVM RAID additionally to {{ic|lvm2}} or {{ic|sd-lvm2}} hooks, you need to add {{ic|dm-raid}} and the appropriate RAID modules (e.g. {{ic|raid0}}, {{ic|raid1}}, {{ic|raid10}} and/or {{ic|raid456}}) to the MODULES array in {{ic|mkinitcpio.conf}}.<br />
<br />
For busybox based initramfs:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=('''dm-raid raid0 raid1 raid10 raid456''')<br />
HOOKS=(base '''udev''' ... block '''lvm2''' filesystems)<br />
}}<br />
<br />
For systemd based initramfs:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=('''dm-raid raid0 raid1 raid10 raid456''')<br />
HOOKS=(base '''systemd''' ... block '''sd-lvm2''' filesystems)<br />
}}<br />
<br />
== Graphical configuration ==<br />
<br />
There is no "official" GUI tool for managing LVM volumes, but {{AUR|system-config-lvm}} covers most of the common operations, and provides simple visualizations of volume state. It can automatically resize many file systems when resizing logical volumes.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Changes that could be required due to changes in the Arch-Linux defaults ===<br />
<br />
The {{ic|1=use_lvmetad = 1}} must be set in {{ic|/etc/lvm/lvm.conf}}. This is the default now - if you have a {{ic|lvm.conf.pacnew}} file, you must merge this change.<br />
<br />
=== LVM commands do not work ===<br />
<br />
* Load proper module:<br />
<br />
# modprobe dm_mod<br />
<br />
The {{ic|dm_mod}} module should be automatically loaded. In case it does not, you can try:<br />
{{Accuracy|Should module loading at boot be done using "/etc/modules-load.d" instead?}}<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=(dm_mod ...)<br />
}}<br />
<br />
You will need to [[regenerate the initramfs]] to commit any changes you made.<br />
<br />
* Try preceding commands with ''lvm'' like this:<br />
<br />
# lvm pvdisplay<br />
<br />
=== Logical Volumes do not show up ===<br />
<br />
If you are trying to mount existing logical volumes, but they do not show up in {{ic|lvscan}}, you can use the following commands to activate them:<br />
<br />
# vgscan<br />
# vgchange -ay<br />
<br />
=== LVM on removable media ===<br />
<br />
Symptoms:<br />
{{hc|# vgscan|<br />
Reading all physical volumes. This may take a while...<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error<br />
Found volume group "backupdrive1" using metadata type lvm2<br />
Found volume group "networkdrive" using metadata type lvm2<br />
}}<br />
<br />
Cause:<br />
:Removing an external LVM drive without deactivating the volume group(s) first. Before you disconnect, make sure to:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Fix: assuming you already tried to activate the volume group with {{ic|vgchange -ay ''vg''}}, and are receiving the Input/output errors:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Unplug the external drive and wait a few minutes:<br />
<br />
# vgscan<br />
# vgchange -ay ''volume group name''<br />
<br />
=== Resizing a contiguous logical volume fails ===<br />
<br />
If trying to extend a logical volume errors with:<br />
<br />
" Insufficient suitable contiguous allocatable extents for logical volume "<br />
<br />
The reason is that the logical volume was created with an explicit contiguous allocation policy (options {{ic|-C y}} or {{ic|--alloc contiguous}}) and no further adjacent contiguous extents are available (see also [http://www.hostatic.ro/2010/02/15/lvm-inherit-and-contiguous-policies/ reference]).<br />
<br />
To fix this, prior to extending the logical volume, change its allocation policy with {{ic|lvchange --alloc inherit <logical_volume>}}. If you need to keep the contiguous allocation policy, an alternative approach is to move the volume to a disk area with sufficient free extents (see [http://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents]).<br />
<br />
=== Command "grub-mkconfig" reports "unknown filesystem" errors ===<br />
<br />
Make sure to remove snapshot volumes before [[GRUB#Generate the main configuration file|generating grub.cfg]].<br />
<br />
=== Thinly-provisioned root volume device times out ===<br />
<br />
With a large number of snapshots, {{ic|thin_check}} runs for a long enough time so that waiting for the root device times out. To compensate, add the {{ic|1=rootdelay=60}} kernel boot parameter to your boot loader configuration.<br />
<br />
=== Delay on shutdown ===<br />
<br />
If you use RAID, snapshots or thin provisioning and experience a delay on shutdown, make sure {{ic|lvm2-monitor.service}} is [[started]]. See {{Bug|50420}}.<br />
<br />
== See also ==<br />
<br />
* [http://sourceware.org/lvm2/ LVM2 Resource Page] on SourceWare.org<br />
* [http://wiki.gentoo.org/wiki/LVM LVM] article at Gentoo wiki<br />
* [http://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][http://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 detals snapshots]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/index.html Red Hat: Logical Volume Manager Administration]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Talk:Security&diff=518046Talk:Security2018-04-20T15:35:59Z<p>Phil.r.dubois: /* Improving the password section */ agreeing</p>
<hr />
<div>==Todo==<br />
*Update "Lockout user after three failed login attempts", file mentioned no longer contains those lines ? <br />
*descriptions/rationale for all the links to other articles (MAC)<br />
*base64 /dev/urandom | dd bs=1 count=10 2>/dev/null<br />
*use (enhanced?) ACL on partitions<br />
*[[Disk quota|quotas]]<br />
*limits/cgroups<br />
*sudo timeout<br />
*DNSSEC<br />
*[[Securely Wipe HDD]]<br />
*[[Using File Capabilities Instead Of Setuid]]<br />
*VNC, proxies, ssl, etc<br />
*rvim/rgvim<br />
*browser security (requestpolicy, noscript, sand-boxing browser)<br />
*PAX/<s>grsecurity</s><br />
*stack protector gcc flag: Put some text in the page indicationg Archlinux has it by default (See: [https://bugs.archlinux.org/task/18864 FS#18864])<br />
* run services as non-root (mention that Arch does this where possible by default - but it needs improvement via feature requests)<br />
* run services in clean namespaces<br />
* run services in chroots<br />
* mention issues with sudo (any X11 application can grab the password, and it is a large setuid binary with potential vulnerabilities)<br />
* describe password expiry policies (chage, passwd -X, etc.)<br />
--[[User:Thestinger|thestinger]] 18:09, 11 January 2011 (EST), --[[User:Det|Det]] ([[User talk:Det|talk]]) 11:35, 3 January 2013 (UTC),<br />
--[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 13:49, 19 April 2013 (UTC)<br />
-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:45, 12 August 2013 (UTC)<br />
<br />
== CentOS Wiki OS Protection Article ==<br />
<br />
Hello,<br />
<br />
This seems to be a good article to cross-reference or to use as a basis to pull in more content here. CC BY SA rights so I suspect it is compatible with the Arch Wiki. http://wiki.centos.org/HowTos/OS_Protection<br />
<br />
I am hoping to pull some content in myself, but I am by no means a security guy. I figured some wiser heads might be able to make better use of it than I or correct any mistakes I might make while attempting to contribute.<br />
<br />
Cheers,<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 22:29, 1 August 2013 (UTC)<br />
<br />
:Of course the information itself is not licensed/licenseable, however the way it is presented is, so you either study the original article and present the same information here in an original way, or you actually adapt some content from that article, but in that case the licence clearly states that you have to credit the original authors, and ''I guess'' you can do it by mentioning the original article in the Summary of your edits, and adding a link to [[Security#See also]].<br />
:Just as a clarification, I know that [[Help:Style#Hypertext metaphor]] states "If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information", however in this case we can't talk about "upstream documentation", that's why the rule doesn't apply and duplication of information is allowed, being CentOS's and Arch's wikis on the "same level" with respect to the information provided.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:33, 3 August 2013 (UTC)<br />
<br />
:: Let's first compare the sections in the two articles and see how they relate:<br />
::* '''Modifying fstab''' -> [[Security#Partitions]].<br />
::* '''Package installs''' -> We have [[Security#Authenticating_packages]] and a note at the bottom of [[Security#Partitions]].<br />
::** We ''definitely'' should talk about [[Pacman#Package_security]] in more depth. That is, we should have a general overview of the function of [[Pacman-key]] and why it is important from a security perspective. [[Pacman-key]] mentions the function of the utility, but not its importance from a security perspective.<br />
::* '''Physical protection''' -> [[Security#Physical_security]]<br />
::* '''Restricting root''' -> We have [[Security#Use_sudo_instead_of_su]] which is a good start, but does not mention [[Ssh#Deny_root_login]]. File system permissions on {{ic|/root}}, which I think by default are not {{ic|700}} (they should be) should be added to [[Security#Filesystem permissions]].<br />
::* '''Umask restrictions''' -> We should talk about {{ic|umask}} in [[Security#Filesystem permissions]].<br />
::* '''Pam modifications''' -> [[Realtime process management]], a wiki page in desperate need of editing.<br />
::* '''Reaping idle users''' -> We should cover this in [[Security#User_setup]].<br />
::* '''Restricting cron and at''' -> We have no equivalent.<br />
::* '''Wireless has to go''' -> Maybe worth talking about, but this is low-priority unless we are willing to write a more detailed section called "Wireless security" that is about more than just "turn off wireless."<br />
::* '''Sysctl Security''' -> Covered in [[Sysctl#TCP/IP stack hardening]], maybe we should just link to this.<br />
::* '''Using TCP Wrappers''' -> I could not find anything on ArchWiki discussing general security practices for {{ic|/etc/hotss}}.<br />
::* '''Beefing up IPTables''' -> Should be adapted into [[Iptables]], but perhaps [[Simple Stateful Firewall]] (an article that has good information, but I am not sure if its name makes sense).<br />
::* '''Tamper Resistance''' -> We should have a section on '''logging''' in general and incorporate tools like this, probably.<br />
::Comments ''highly'' appreciated.<br />
::-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 05:09, 3 August 2013 (UTC)<br />
:::If you want to start working in this direction, go for it! :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 5 August 2013 (UTC)<br />
<br />
== Grsecurity sections ==<br />
<br />
We now have three sections devoted only to Grsecurity. What can we do about this?<br />
<br />
The [https://wiki.archlinux.org/index.php?title=Security&diff=272330&oldid=272327 addition] of [[Security#Grsecurity RBAC]] seems to be redundant. However, I agree that "RBAC" is a better name for Grsecurity's MAC implementaiton than [[Security#Access Control Lists]]. In technical terms ACLs are a subset of RBAC and Grsecurity implmeents both. The Grsecurity patchset [https://www.cs.virginia.edu/~jcg8f/GrsecuritySELinuxCaseStudy.pdf only had ACLs][PDF] back in 2005, and the cited case study mentions (it also refers to SELinux as a RBAC implementation, so perhaps SELinux should also be mentioned there):<br />
<br />
:This implementation of ACLs creates a form of process-based mandatory access control. It is possible to restrict what a process can and cannot do. Additionally, access can be restricted to an object for any user, even root. Further, these restrictions cannot be changed by normal users. The system will soon offer role-based access control as well. <br />
<br />
Probably the right solution for this is:<br />
<br />
* Rename [[Security#Grsecurity RBAC]] to [[Security#Role-Based Access Control]].<br />
* Discuss both SELinux/Grsecurity implementations there. There is no need for the RBAC section to be Grsecurity-specific.<br />
<br />
[[Security#Kernel Hardening]] is only about [[Grsecurity]] but I am not sure if it should be merged into [[Security#Mandatory access control|Mandatory access control]] as suggested.<br />
<br />
* I think it is best to give general recommendations here rather than something like "install Grsecurity to make your kernel secure".<br />
* The right solution is probably to expand [[Security#Kernel Hardening]] and discuss [[Wikipedia:PaX]] and whatnot more generally, mentioning Grsecurity as an implementation. <br />
* I do think [[Security#Kernel Hardening]] should probably be moved lower on the page, closer to [[Security#Mandatory access control]]/[[Security#Network and Firewalls]]/[[Security#Authenticating packages]] since that seems to better suit the logical flow of the article.<br />
<br />
-- [[User:Ndt|Ndt]] ([[User Talk:Ndt|talk]]) 21:36, 4 September 2013 (UTC)<br />
<br />
:I can't comment on the content since I don't know much about it, but allow me to add some notes:<br />
:# The different security models (RBAC, MAC, DAC, ACL, ...) should be compared/described separately from the individual implementations (SELinux, Tomoyo, AppArmor, ...). Meaning there should be separate sections for each group, but mainly ''"RBAC is significantly faster then SELinux."'' does not make much sense.<br />
:# There should always be provided alternatives, not just 1:1 mapping (like in case of RBAC and Grsecurity).<br />
:# Descriptions of both ''groups'' can be provided from multiple perspectives. From my experience, in these situations a comparison table is often the best solution.<br />
:I'm not sure about the [[Security#Kernel Hardening]] section, should it focus only on security options that require patching the Arch kernel, or also those included in Arch kernel but not activated?<br />
:I hope it makes sense...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:09, 4 September 2013 (UTC)<br />
::+1, also on mentioning the other options. I further agree with Ndt, moving [[Security#Kernel Hardening]] down to below (or above?) [[Security#Mandatory_access_control]] and merging the bits for [[Security#Kernel_parameters]] into it is better flow, then any other options that are avail without patching into it, followed by PAX and the existing Grsecurity so those get mentioned just before MAC. If someone wants to work on that: I like the comparison/table [http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html here] maybe it gives some inspiration how to expand. If not, maybe good for See also. (further comparisons are at the bottom of the link). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:05, 5 September 2013 (UTC)<br />
<br />
== Nobody as script user ==<br />
<br />
[[Systemd/cron_functionality#The_pkgstats_service]] article says that it is better to use {{ic|noboby}} for some tipe of scripts. Is there any person who can explain further and add a note in this article?<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:29, 13 September 2013 (UTC)<br />
<br />
: Following the [[Wikipedia:Principle of least privilege|principle of least privilege]] it is logical to run as many scripts as possible as an unprivileged user. But this is not possible always, e.g. when the script needs (write) access to some file(s) to function properly, you need to provide those privileges. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:32, 13 September 2013 (UTC)<br />
::It's not actually a good idea to do this. Processes running as {{ic|nobody}} can ptrace each other, so there is a loss of security if more than one thing is run as that users. Ideally, individual users would be created for each case. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 10:52, 31 March 2014 (UTC)<br />
<br />
== Improving the password section ==<br />
<br />
This is a call for ideas and community effort to improve the password recommendations here. I think it's generally agreed that the password section needs (and has, for a long time, needed) some work.<br />
<br />
What does the password section need? Is it even necessary - does it make sense for someone to get this information from a wiki? How can we back up our statements, so that we know that the password recommendations made aren't just totally arbitrary (e.g, "at least one number ...")? <br />
<br />
Citing sources, I think, is useful here - even though there's an element of password generation that is a matter of opinion, there are many recommendation that can be made that are ''not'' opinion. Just my two cents. - [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 21:51, 29 August 2014 (UTC)<br />
<br />
:A part I question is: <br />
<br />
::''Insecure passwords include... Phrases of known words (e.g., all of the lights, correct horse battery staple), even with character substitution.''<br />
<br />
:How about [http://world.std.com/~reinhold/diceware.html Diceware] (mentioned in [[Disk_encryption#Choosing_a_strong_passphrase]], which is linked to at the end of the section) ? --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:48, 31 August 2014 (UTC)<br />
<br />
::I've added some clarifications to that sentence: [https://wiki.archlinux.org/index.php?title=Security&diff=333453&oldid=333379].<br />
::The whole problem comes down to the bits of entropy of a passphrase: if calculated against brute-force attacks, every character from the chosen set counts, because in general they are not releated to each other. In case of Diceware, the characters inside each word ''are'' related to each other, and instead what is independent are the words themselves, so the bits must be calculated on a per-word basis (it's vulnerable to dictionary attacks, which can be seen as a form of brute-force attack with every word representing a character in a set of 7776). Now, as you can see from the table in [[Wikipedia:Password strength]], a set of 5 Diceware words is equal to e.g. 10 ASCII characters (64 bits); 7 words == 13 ASCII. Nowadays you'd need more than that to be "safe", but in the end it mostly depends on the importance of what you want to protect. Of course if you choose a phrase of words that are also grammatically related with each other, you're exposing it to some smart dictionary attacks, which would further lower the total bits of entropy.<br />
::Actually, that whole section could be questioned, in fact I could make a strong password even with "Root words or common strings followed or preceded by added numbers, symbols, or characters", if I chose enough "root words" and numbers; I could even make a strong password with dictionary words grammatically related, if the sentence was long enough :) I hope it makes it clearer.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:34, 1 September 2014 (UTC)<br />
<br />
:::Thanks for clarifying. Maybe add [[Wikipedia:Password strength]] to the article (it's already linked in [[Wikipedia:Password_cracking]], but it wouldn't hurt here)? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 01:32, 2 September 2014 (UTC)<br />
<br />
::::Link added after merging [[Disk_encryption#Choosing_a_strong_passphrase]]. Still, the whole section is very unorganized :( but at least now all the info is gathered in one place. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:16, 3 September 2014 (UTC)<br />
<br />
:::::First time I ever edit or contribute to a Wiki. I added an example of enforcing a password policy using pam_cracklib [[User:Redsolja|Redsolja]] ([[User talk:Redsolja|talk]]) 15:48, 26 April 2015 (UTC)<br />
<br />
::::::Thank you, very well done for a first edit! — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:34, 27 April 2015 (UTC)<br />
<br />
:In the Choosing secure passwords section, I'd like to point out that we're linking to an unencrypted webpage for testing password entropy... [[User:phil.r.dubois|phil.r.dubois]] ([[User talk:phil.r.dubois|talk]]) 23:30, 18 April 2018 (UTC)<br />
<br />
::Thanks, I originally [https://wiki.archlinux.org/index.php?title=Security&diff=518037&oldid=517999 removed] that part without thinking too much, however that test is completely done on the client in Javascript, so theoretically safely, but still I don't see the point of using a website to do that when proper password managers such as Keepass* do the same right where you should be doing it. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:23, 20 April 2018 (UTC)<br />
<br />
:::That explains why it was there in the first place. But yeah, that's a fair assessment. I'd prefer to choose a password manager over trusting the browser any day. [[User:phil.r.dubois|phil.r.dubois]] ([[User talk:phil.r.dubois|talk]]) 15:30, 20 April 2018 (UTC)<br />
<br />
== Removal of incorrect warning ==<br />
<br />
:''Moved from [[User_talk:thestinger]].'' -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:01, 25 February 2015 (UTC)<br />
<br />
Greetings, I have removed [https://wiki.archlinux.org/index.php?title=Security&diff=307743&oldid=307742 the warning] regarding SHA512 on the password hashing section. It's true that one shouldn't use plain sha512 for password hashing, but that isn't what arch (or other Linux distributions) use or are even able to use. What they call "sha512" is crypt_sha512, analogous to cryptmd5 but with the hash function replaced. Crypt_sha512 is a strong sequential function with a configurable iteration parameter. Normal configurations are fairly slow by default and are configurable to be arbritarily slow. I also updated the text to make it clear that it used an iterated sha512 so that others would be less likely to suffer from your confusion. Cheers. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:39, 24 December 2014 (UTC)<br />
<br />
:I was fully aware that it runs a configurable number of sha512 iterations when I made the change. It's not enough iterations to make up for how cheap it is relative to bcrypt/scrypt and it requires very little memory so it does nothing to counter doing billions of hashes per second on a GPU. I don't care enough to argue about it but you shouldn't assume that it had anything to do with confusion. -- [[User:thestinger|thestinger]] 23:48, 24 December 2014 (UTC)<br />
<br />
::Reverted OP's removal a while ago, so this can be closed. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:23, 19 January 2015 (UTC)<br />
<br />
:::It may not be wrong, but it’s still misleading, and conflicts with the immediately following paragraph. Is there a nice way to change each to satisfy everyone? -- [[User:Charmander|Charmander]] ([[User talk:Charmander|talk]]) 19:12, 19 January 2015 (UTC)<br />
<br />
:: I have rephrased the first sentence of the following paragraph to "''The default Arch hash [[SHA_password_hashes|sha512]] is, however, different than plain SHA512. It is very strong and there is no need to change it.''" in an attempt to remove the inconsistency. Please proof-read this, since I am a no cryptography expert - the '''only''' source I was using was this very discussion. Also I am not native to English, so I can't guarantee I was grammatically correct. Here is the diff to my edit: [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393653&oldid=383265] [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:30, 24 August 2015 (UTC)<br />
<br />
::: I don't understand what this changes - how is the SHA512 sum ''different'' (considering thestinger's argument above) ? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:36, 24 August 2015 (UTC)<br />
<br />
:::: AFAIK the Arch's SHA512 iterates, while plain SHA512 doesn't? Anyway, if what I wrote is wrong, please revert it. But if you do, please do fix the inconsistency in a more competent way. The original phrasing is misleading and just cannot last any more. [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:42, 24 August 2015 (UTC)<br />
<br />
::::: See [https://wiki.archlinux.org/index.php?title=Security&diff=393663&oldid=393653]. Perhaps we should also add how the number of iterations could be increased (maximum is 999 999 999, according to man passwd). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:49, 24 August 2015 (UTC)<br />
<br />
:::::: Added with [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393665&oldid=393663]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:56, 24 August 2015 (UTC)<br />
:::::: edit: going to undo this since I don't know what's meant above with "not enough". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:57, 24 August 2015 (UTC)<br />
<br />
::::::: One more thing. Your phrasing does not state whether or not these 5000 iterations, in association with storing passwords in /etc/shadow, actually are secure. With the nearby warning, an impression is made that in might not be enough and that the wiki advises the user to use something else. You have removed this important sentence: "''It is very strong and there is no need to change it''". If this is appropriate, could you kindly explicitly state whether or not this default Arch's hashing is considered secure enough for normal desktop use? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:00, 24 August 2015 (UTC)<br />
<br />
:::::::: I'm not the expert, but I'd assume 5000 iterations is "not enough". However I don't know if 999 999 999 or any arbitray high amount is "enough" either. This assessment likely changes as hardware gets more powerful, or more efficient methods are discovered.<br />
:::::::: The fact that the hashes are stored in {{ic|/etc/shadow}} should be sufficient, but I don't know how to accurately word that ("can't be copied or cracked" is vague at best). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:05, 24 August 2015 (UTC)<br />
<br />
::::::::: I'm honestly unsure if I'm nitpicking or if this is a serious problem. Anyway I [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393676&oldid=393670 have put] a Template:Expansion. Hope that's OK? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:23, 24 August 2015 (UTC)<br />
<br />
:::::::::: Sure, thanks. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:02, 24 August 2015 (UTC)<br />
<br />
:::::::::::I have practically rewritten the section with [https://wiki.archlinux.org/index.php?title=Security&diff=410426&oldid=409966 these 3 edits], adding lots of links so that people can try to better understand this complicated process.<br />
:::::::::::Functions like bcrypt and scrypt are indeed aimed at making it more expensive to brute-force passwords with custom-hardware attacks, but if we don't tell people how to ''decide'' what function to use, and how to ''set'' it up, a warning like that is only FUD...<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:29, 28 November 2015 (UTC)<br />
<br />
== Let's forget about limits.conf? ==<br />
<br />
Look rapidly at [https://sskaje.me/systemd-ulimit/ this] blog post.<br />
<br />
In short: '''limits.conf is useless''' for systemd daemons, because systemd has it's own ''LimitNOFILE=123456'', ''LimitETC=50K''.<br />
<br />
This is also an issue for desktop users, because users implemented via slices, services and User Manager.<br />
<br />
To set per-user resource-limits, now do the following:<br />
<pre><br />
mkdir -p /etc/systemd/system/user@1000.service.d/<br />
cat > /etc/systemd/system/user@1000.service.d/limits.conf << EOF<br />
[Service]<br />
LimitNFILE=131072<br />
EOF<br />
systemd daemon-reload<br />
systemd restart user@1000<br />
</pre><br />
<br />
'''1000''' -- is a user's uid. Optional.<br />
<br />
The archwiki is full of useless limits.conf documentation, it is time to update it, or i've missing something? [[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 09:51, 16 December 2015 (UTC)<br />
<br />
:: Oops, looks like all this info valid only for dbus-activated user apps like gnome-terminal.<br />
::[[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 14:14, 16 December 2015 (UTC)<br />
<br />
== pam_tally ==<br />
<br />
According to the PAM SAG pam_tally is deprecated and should be replaced by pam_tally2. I suggest to update the page accordingly. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 20:20, 7 February 2016 (UTC)<br />
<br />
:Is the information in the manpage for pam_tally2 accurate? I don't know PAM, and I'm not fully comfortable with changing the page without asking first. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 00:01, 18 June 2016 (UTC)<br />
<br />
::Good you ask, such should indeed be tested before updating. Please check [https://bugs.archlinux.org/task/42120#comment148179] as input when you go about changing the section. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:58, 18 June 2016 (UTC)<br />
<br />
:::If pam_tally2 is going to be deprecated soon anyway in favour of pam_faillock, then updating the page right now seems a bit pointless. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 11:28, 18 June 2016 (UTC)<br />
<br />
::::Well, the faillock module has not landed in the package for years, that part remains to be seen. Updating is useful I think, because due to the nature of the pam project they rarely remove modules (since that can severly break existing installations). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:40, 19 June 2016 (UTC)<br />
<br />
::I've run into a couple of problems:<br />
::#pam_tally, the original one, seems to have a default configuration in place, and I'm not sure what steps are needed to completely disable it. Is it enough to remove its line from {{ic|/etc/pam.d/system-login}}, or is there something more to be done? <br />
::#In [https://bugs.archlinux.org/task/42120#comment148179] it's mentioned that pam_tally2 should be added to account pam_tally2.so in the stack as well, but I don't know this should be done. I've gathered that I need to add the line {{ic|account required pam_tally2.so}} to some account section somewhere, but I don't know which file specifically I should be editing.<br />
::I would suggest that this be left to someone who has a better understanding of how PAM works. --[[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 16:37, 21 June 2016 (UTC)<br />
<br />
== Using systemd for more secure services ==<br />
<br />
I saw [https://lwn.net/SubscriberLink/709755/a3b534d94fc57157/ this article] that lists several options for systemd units to help protect one's system. I think some of these should be added to our article. In particular {{man|5|systemd.exec}} recommends setting/enabling {{ic|ProtectHome}}, {{ic|ProtectSystem}}, {{ic|ProtectKernelTunables}}, {{ic|ProtectControlGroups}}, {{ic|RestrictRealtime}} for most long-running services. Some of these are simple boolean options. Others have different levels that can be set. Lennart lists these and others [https://lwn.net/Articles/709764/ here]. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 19:40, 3 January 2017 (UTC)<br />
:Working on a draft of some ideas here: [[User:Rdeckard/Secure Systemd]] -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:10, 5 January 2017 (UTC)<br />
<br />
== grsecurity End of Support ==<br />
<br />
There was a proposal to archive, I think this is a mistake until we know more about how this shakes out. There have been some rumblings that Gentoo Hardened may take over primary development of a branch of the 3.1 patchset. Alternatively, I've already reached out to the Grsecurity team to ask about individual licensing. As Arch is an open source community, it's not unreasonable that there could be some very reasonable individual license. If so, we could probably move the package to the AUR, and users would need to buy a license.<br />
<br />
Finally, the last released patch was for 4.9, which is a stable kernel branch -- there's no reason to kill the wiki just yet, as 4.9 will not be EOL for a long time.<br />
<br />
[[User:Osteichthyes|Osteichthyes]] ([[User talk:Osteichthyes|talk]]) 23:56, 27 April 2017 (UTC)<br />
<br />
:3.1 doesn't work on Arch since systemd requires at least 3.14 or higher, and I somehow doubt that the Arch developers or TUs are willing to cash out for a grsecurity license. Regarding the stance on 4.9, see this post by the maintainer: https://lists.archlinux.org/pipermail/arch-general/2017-April/043612.html {{Unsigned|19:05, 27 April 2017|Alad}}<br />
<br />
::There's a gradm ABI version included in the version, but it doesn't have the importance that they think it does. The grsecurity version is the kernel version + the grsecurity timestamp. That 3.1 version is only relevant to RBAC / gradm, and RBAC certainly has a lot of improvements without that version changing since I think it's only for breaking changes to the ABI. -- [[User:thestinger|thestinger]] 16:22, 29 April 2017 (UTC)<br />
<br />
:If things change and grsecurity is available in some form to Arch Linux users, I don't think it would be hard to resurrect the page (or parts of it) from the archive. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 23:33, 28 April 2017 (UTC)<br />
<br />
:There isn't going to be individual licensing. If someone takes over maintenance, it needs to be renamed from PaX and grsecurity so there will need to be a new name for this page and a bunch of configuration and tool naming may end up being updated to match the new name if it's a true fork with active development. Maintaining the 4.9 patch is a dead end and if that's all that happens, it's over. Either way, I'm not maintaining it anymore including paxd and the exceptions being a dead project. I saw this coming for a long time, so I haven't been putting much work into it for a while and now it's over. The most I'll consider is a package enabling the Kernel Self Protection Project features... which is such a tiny portion of what was provided. Key features like RAP are going to be unavailable for 5+ years if they even land at all. -- [[User:thestinger|thestinger]] 16:17, 29 April 2017 (UTC)<br />
<br />
<br />
== Kernel hardening - disabling jit compiler ==<br />
<br />
Currently, this page advises to disable bpf jit compiler by setting ''net.core.bpf_jit_enable'' to 0. Doing so causes error:<br />
<pre><br />
$ sudo sysctl -w net.core.bpf_jit_enable=0 <br />
sysctl: setting key "net.core.bpf_jit_enable": Invalid argument<br />
net.core.bpf_jit_enable = 0<br />
</pre><br />
This commit in the linux repo from January seems to indicate that disabling the jit compiler is not longer possible (or desirable): [https://github.com/torvalds/linux/commit/290af86629b25ffd1ed6232c4e9107da031705cb commit on Github torvalds/linux]. There is however a ''net.core.bpf_jit_harden'' flag available. I do not have the necessary knowledge to decide on what the best course of action is and edit the pages. Should the ''Keep BPF JIT compiler disabled'' section be removed? Is the''bpf_jit_harden'' flag advisable? [[User:Gthau|Gthau]] ([[User talk:Gthau|talk]]) 18:34, 26 March 2018 (UTC)</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Security&diff=517999Security2018-04-20T05:28:27Z<p>Phil.r.dubois: /* Physical security */ added Boot partition on removable flash drive</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 [[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 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|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]]).<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 />
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 {{man|8|pam_cracklib}} and {{man|8|pam_unix}} 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 />
!Partition<br />
!{{ic|nodev}}<br />
!{{ic|nosuid}}<br />
!{{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 />
=== 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 after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}} to read as:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=#%PAM-1.0<br />
<br />
auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed<br />
account required pam_tally2.so<br />
}}<br />
<br />
pam_tally is deprecated and superseded by pam_tally2, so you will want to comment out the pam_tally line:<br />
<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<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 --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 />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq -c}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] often is considered as insecure. Thus it is recommended to avoid running Xorg as root, like it is usually the default configuration.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run Xorg sessions without root privileges for Xorg process.<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#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 />
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 />
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'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 />
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=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 />
{{Warning|This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).}}<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 user sessions to work correctly, 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 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 />
[[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 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 />
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 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 />
[[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 />
[[Wikipedia:DNS|Domain Name System]] 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. You nor your browser would be aware since the DNS query was believed to be legitimate. <br />
<br />
[[DNSSEC]] is a set of standards in place that would require 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 could not make modifications to your DNS queries, but would still be able to read them. [[DNSCrypt]] uses cryptography to secure your communications with DNS resolvers.<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 Security 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 />
=== 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 />
=== 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 />
=== Protect against rogue USB devices ===<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 />
* [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://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://archive.fo/wrjIM UNIX and Linux Security Checklist v3.0]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Security&diff=517998Security2018-04-20T04:57:48Z<p>Phil.r.dubois: /* DNS */ provided explanations as to why one would use DNSSEC and DNSCrypt</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 [[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 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|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]]).<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 />
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 {{man|8|pam_cracklib}} and {{man|8|pam_unix}} 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 />
!Partition<br />
!{{ic|nodev}}<br />
!{{ic|nosuid}}<br />
!{{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 />
=== 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 after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}} to read as:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=#%PAM-1.0<br />
<br />
auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed<br />
account required pam_tally2.so<br />
}}<br />
<br />
pam_tally is deprecated and superseded by pam_tally2, so you will want to comment out the pam_tally line:<br />
<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<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 --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 />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq -c}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] often is considered as insecure. Thus it is recommended to avoid running Xorg as root, like it is usually the default configuration.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run Xorg sessions without root privileges for Xorg process.<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#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 />
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 />
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'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 />
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=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 />
{{Warning|This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).}}<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 user sessions to work correctly, 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 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 />
[[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 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 />
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 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 />
[[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 />
[[Wikipedia:DNS|Domain Name System]] 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. You nor your browser would be aware since the DNS query was believed to be legitimate. <br />
<br />
[[DNSSEC]] is a set of standards in place that would require 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 could not make modifications to your DNS queries, but would still be able to read them. [[DNSCrypt]] uses cryptography to secure your communications with DNS resolvers.<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 Security 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 />
=== Protect against rogue USB devices ===<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 />
* [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://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://archive.fo/wrjIM UNIX and Linux Security Checklist v3.0]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Security&diff=517997Security2018-04-20T04:31:59Z<p>Phil.r.dubois: /* SSH */ typo</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 [[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 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|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]]).<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 />
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 {{man|8|pam_cracklib}} and {{man|8|pam_unix}} 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 />
!Partition<br />
!{{ic|nodev}}<br />
!{{ic|nosuid}}<br />
!{{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 />
=== 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 after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}} to read as:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=#%PAM-1.0<br />
<br />
auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed<br />
account required pam_tally2.so<br />
}}<br />
<br />
pam_tally is deprecated and superseded by pam_tally2, so you will want to comment out the pam_tally line:<br />
<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<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 --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 />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq -c}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] often is considered as insecure. Thus it is recommended to avoid running Xorg as root, like it is usually the default configuration.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run Xorg sessions without root privileges for Xorg process.<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#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 />
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 />
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'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 />
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=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 />
{{Warning|This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).}}<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 user sessions to work correctly, 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 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 />
[[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 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 />
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 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 />
[[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 Security 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 />
=== Protect against rogue USB devices ===<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 />
* [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://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://archive.fo/wrjIM UNIX and Linux Security Checklist v3.0]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Audit_framework&diff=517992Audit framework2018-04-20T01:42:43Z<p>Phil.r.dubois: /* Adding rules */ grammar</p>
<hr />
<div>[[Category:Security]]<br />
[[ja:Audit フレームワーク]]<br />
The Linux audit framework provides a CAPP-compliant ([[Wikipedia:Controlled Access Protection Profile|Controlled Access Protection Profile]]) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.<br />
<br />
Linux audit helps make your system more secure by providing you with a means to analyze what is happening on your system in great detail. It does not, however, provide additional security itself—it does not protect your system from code malfunctions or any kind of exploits. Instead, Audit is useful for tracking these issues and helps you take additional security measures, to prevent them.<br />
<br />
The audit framework works by listening to the event reported by the kernel and logging them to a log file.<br />
<br />
{{Accuracy|Is the note about the incompatibility of the audit framework with the linux namespace implementation still valid for the current kernel? If so, are there plans to fix it? If not, then clearly state that in the note!}}<br />
{{Note|As of linux 3.12, the audit framework is not yet compatible with the namespace implementation. If you use namespaces, do not use the audit framework.}}<br />
{{Note|Depending on your configuration, it may affect the performance of the system.}}<br />
<br />
==Installation==<br />
Install a custom kernel with {{ic|CONFIG_AUDIT}} enabled. You can also install {{Pkg|linux-hardened}} package and add {{ic|1=audit=1}} to [[Kernel parameters]] instead.<br />
<br />
Install {{Pkg|audit}} and [[start]]/[[enable]] {{ic|auditd.service}}.<br />
<br />
{{Note|The {{Pkg|linux-hardened}} package by default sets {{ic|1=audit=0}} in [[Kernel parameters]] which conflicts with {{ic|1=ConditionKernelCommandLine=!audit=0}} set in {{ic|/usr/lib/systemd/system/auditd.service}}. To overcome this you may override {{ic|auditd.service}} settings with:<br />
<br />
# systemctl edit auditd.service<br />
<br />
{{hc|head=/etc/systemd/system/auditd.service.d/override.conf|output=<br />
[Unit]<br />
ConditionKernelCommandLine=<br />
ConditionKernelCommandLine=audit=1<br />
}}<br />
}}<br />
<br />
Audit framework is composed of the auditd daemon, responsible for writing the audit messages that were generated through the audit kernel interface and triggered by application and system activity.<br />
<br />
This daemon can be controlled by several commands and files:<br />
* ''auditctl'' : to control the behavior of the daemon on the fly, adding rules etc.<br />
* {{ic|/etc/audit/audit.rules}} : contains the rules and various parameters of the auditd daemon<br />
* ''aureport'' : generate report of the activity on a system<br />
* ''ausearch'' : search for various events<br />
* ''auditspd'' : the daemon which can be used to relay event notifications to other applications instead of writing them to disk in the audit log<br />
* ''autrace'' : this command can be used to trace a process, in a similar way as strace.<br />
* {{ic|/etc/audit/auditd.conf}} : configuration file related to the logging.<br />
<br />
==Adding rules==<br />
Before adding rules, you must know that the audit framework can be very verbose and that each rule must be carefully tested before being effectively deployed. Indeed, just one rule can flood all your logs within a few minutes.<br />
<br />
===Audit files and directories access===<br />
The most basic use of the audit framework is to log the access to the files you want.<br />
To do this, you must use a watch {{ic|-w}} to a file or a directory<br />
The most basic rule to set up is to track accesses to the passwd file :<br />
<br />
# auditctl -w /etc/passwd -p rwxa<br />
<br />
You can track access to a folder with :<br />
<br />
# auditctl -w /etc/security/<br />
<br />
The first rule keeps track of every read {{ic|r}} , write {{ic|w}} , execution {{ic|x}} , attribute change {{ic|a}} to the file {{ic|/etc/passwd}}.<br />
The second one keeps track of any access to the {{ic|/etc/security/}} folder.<br />
<br />
You can list all active rules with :<br />
<br />
# auditctl -l<br />
<br />
You can delete all rules with :<br />
<br />
# auditctl -D<br />
<br />
Once you validate the rules, you can append them to the {{ic|/etc/audit/audit.rules}} file like that : <br />
<br />
-w /etc/audit/audit.rules -p rwxa<br />
-w /etc/security/<br />
<br />
===Audit syscalls===<br />
The audit framework allows you to audit the syscalls performed with the {{ic|-a}} option.<br />
<br />
A security related rule is to track the {{ic|chmod syscall}}, to detect file ownership changes :<br />
<br />
auditctl -a entry,always -S chmod<br />
<br />
For a list of all syscalls: {{man|2|syscalls}}<br />
<br />
A lot of rules and posibilities are available, see {{man|8|auditctl}} and {{man|7|audit.rules}}.<br />
<br />
==Search the logs==<br />
The audit framework provides some tools to ease the use and the research of events happening on a system.<br />
===using pid===<br />
You can search events related to a particular pid using {{ic|ausearch}}:<br />
<br />
# ausearch -p 1<br />
<br />
This command will show you all the events logged according to your rules related to PID 1 (i.e. systemd).<br />
<br />
===using keys===<br />
One of the great features of the audit framework is its hability to use {{ic|keys}} to manage events, such a usage is recommended.<br />
<br />
You can use the {{ic|-k}} option in your rules to be able to find related events easily :<br />
<br />
# auditctl -w /etc/passwd -p rwxa -k KEY_pwd<br />
<br />
Then, if you search for events with the key {{ic|KEY_pwd}}, ausearch will display only event related to the file {{ic|/etc/passwd}}.<br />
<br />
# ausearch -k KEY_pwd<br />
<br />
===Look for abnormalies===<br />
The {{ic|aureport}} tool can be used to quickly report any anormal event performed on the system, it includes network interfaces used in promiscous mode, process or thread crashing or exiting with ENOMEM error etc.<br />
<br />
The easiest way to use {{ic|aureport}} is :<br />
<br />
# aureport -n<br />
<br />
aureport can be used to generate custom reports, see {{man|8|aureport}}.<br />
<br />
==Which files or syscalls are worth-auditing ?==<br />
Keep in mind that each audit rule added will generate logs, so you must be ready to treat this amount of information.<br />
Basically, each security-related event/file must be monitored, like ids, ips, anti-rootkits etc.<br />
On the other side, it's totally useless to track every write syscall, the smallest compilation will fill your logs with this event.<br />
<br />
More complex set of rules can be set up, performing auditing on a very fine-grained base. If you want to do so, see {{man|8|auditctl}}.<br />
<br />
==Gather logs from different hosts==<br />
The audit framework has a plugin system which provides the possibility to send local logfiles to a remote auditd.<br />
<br />
=== Send logfiles ===<br />
To send your logfiles to a remote host you need the {{ic|audisp-remote}} plugin which comes automatically with the {{Pkg|audit}} package.<br />
Activate the plugin:<br />
{{hc|head=/etc/audisp/plugins.d/au-remote.conf|output=<br />
active = yes<br />
direction = out<br />
path = /usr/bin/audisp-remote<br />
type = always<br />
format = string<br />
}}<br />
<br />
and set the remote host where the logs should be send to:<br />
<br />
{{hc|head=/etc/audisp/audisp-remote.conf|output=<br />
remote_server = domain.name.or.ip<br />
port = 60<br />
##local_port = optional<br />
transport = tcp<br />
}}<br />
<br />
=== Receive logfiles ===<br />
To make audit listen for remote audispds you just need to set the tcp options:<br />
{{hc|head=/etc/audit/auditd.conf|output=<br />
tcp_listen_port = 60<br />
tcp_listen_queue = 5<br />
tcp_max_per_addr = 1<br />
##tcp_client_ports = 1024-65535 #optional<br />
tcp_client_max_idle = 0<br />
}}<br />
<br />
Now you can view the logs of '''all''' configured hosts in the logfiles of the receiving auditd.</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Audit_framework&diff=517991Audit framework2018-04-20T01:41:23Z<p>Phil.r.dubois: Grammar</p>
<hr />
<div>[[Category:Security]]<br />
[[ja:Audit フレームワーク]]<br />
The Linux audit framework provides a CAPP-compliant ([[Wikipedia:Controlled Access Protection Profile|Controlled Access Protection Profile]]) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.<br />
<br />
Linux audit helps make your system more secure by providing you with a means to analyze what is happening on your system in great detail. It does not, however, provide additional security itself—it does not protect your system from code malfunctions or any kind of exploits. Instead, Audit is useful for tracking these issues and helps you take additional security measures, to prevent them.<br />
<br />
The audit framework works by listening to the event reported by the kernel and logging them to a log file.<br />
<br />
{{Accuracy|Is the note about the incompatibility of the audit framework with the linux namespace implementation still valid for the current kernel? If so, are there plans to fix it? If not, then clearly state that in the note!}}<br />
{{Note|As of linux 3.12, the audit framework is not yet compatible with the namespace implementation. If you use namespaces, do not use the audit framework.}}<br />
{{Note|Depending on your configuration, it may affect the performance of the system.}}<br />
<br />
==Installation==<br />
Install a custom kernel with {{ic|CONFIG_AUDIT}} enabled. You can also install {{Pkg|linux-hardened}} package and add {{ic|1=audit=1}} to [[Kernel parameters]] instead.<br />
<br />
Install {{Pkg|audit}} and [[start]]/[[enable]] {{ic|auditd.service}}.<br />
<br />
{{Note|The {{Pkg|linux-hardened}} package by default sets {{ic|1=audit=0}} in [[Kernel parameters]] which conflicts with {{ic|1=ConditionKernelCommandLine=!audit=0}} set in {{ic|/usr/lib/systemd/system/auditd.service}}. To overcome this you may override {{ic|auditd.service}} settings with:<br />
<br />
# systemctl edit auditd.service<br />
<br />
{{hc|head=/etc/systemd/system/auditd.service.d/override.conf|output=<br />
[Unit]<br />
ConditionKernelCommandLine=<br />
ConditionKernelCommandLine=audit=1<br />
}}<br />
}}<br />
<br />
Audit framework is composed of the auditd daemon, responsible for writing the audit messages that were generated through the audit kernel interface and triggered by application and system activity.<br />
<br />
This daemon can be controlled by several commands and files:<br />
* ''auditctl'' : to control the behavior of the daemon on the fly, adding rules etc.<br />
* {{ic|/etc/audit/audit.rules}} : contains the rules and various parameters of the auditd daemon<br />
* ''aureport'' : generate report of the activity on a system<br />
* ''ausearch'' : search for various events<br />
* ''auditspd'' : the daemon which can be used to relay event notifications to other applications instead of writing them to disk in the audit log<br />
* ''autrace'' : this command can be used to trace a process, in a similar way as strace.<br />
* {{ic|/etc/audit/auditd.conf}} : configuration file related to the logging.<br />
<br />
==Adding rules==<br />
Before adding rules, you must know that the audit framework can be very verbose and that each rules must be carefully tested before being effectively deployed. Indeed, just one rule can flood all your log within a few minutes.<br />
<br />
===Audit files and directories access===<br />
The most basic use of the audit framework is to log the access to the files you want.<br />
To do this, you must use a watch {{ic|-w}} to a file or a directory<br />
The most basic rule to set up is to track accesses to the passwd file :<br />
<br />
# auditctl -w /etc/passwd -p rwxa<br />
<br />
You can track access to a folder with :<br />
<br />
# auditctl -w /etc/security/<br />
<br />
The first rule keeps track of every read {{ic|r}} , write {{ic|w}} , execution {{ic|x}} , attribute change {{ic|a}} to the file {{ic|/etc/passwd}}.<br />
The second one keeps track of any access to the {{ic|/etc/security/}} folder.<br />
<br />
You can list all active rules with :<br />
<br />
# auditctl -l<br />
<br />
You can delete all rules with :<br />
<br />
# auditctl -D<br />
<br />
Once you validate the rules, you can append them to the {{ic|/etc/audit/audit.rules}} file like that : <br />
<br />
-w /etc/audit/audit.rules -p rwxa<br />
-w /etc/security/<br />
<br />
===Audit syscalls===<br />
The audit framework allows you to audit the syscalls performed with the {{ic|-a}} option.<br />
<br />
A security related rule is to track the {{ic|chmod syscall}}, to detect file ownership changes :<br />
<br />
auditctl -a entry,always -S chmod<br />
<br />
For a list of all syscalls: {{man|2|syscalls}}<br />
<br />
A lot of rules and posibilities are available, see {{man|8|auditctl}} and {{man|7|audit.rules}}.<br />
<br />
==Search the logs==<br />
The audit framework provides some tools to ease the use and the research of events happening on a system.<br />
===using pid===<br />
You can search events related to a particular pid using {{ic|ausearch}}:<br />
<br />
# ausearch -p 1<br />
<br />
This command will show you all the events logged according to your rules related to PID 1 (i.e. systemd).<br />
<br />
===using keys===<br />
One of the great features of the audit framework is its hability to use {{ic|keys}} to manage events, such a usage is recommended.<br />
<br />
You can use the {{ic|-k}} option in your rules to be able to find related events easily :<br />
<br />
# auditctl -w /etc/passwd -p rwxa -k KEY_pwd<br />
<br />
Then, if you search for events with the key {{ic|KEY_pwd}}, ausearch will display only event related to the file {{ic|/etc/passwd}}.<br />
<br />
# ausearch -k KEY_pwd<br />
<br />
===Look for abnormalies===<br />
The {{ic|aureport}} tool can be used to quickly report any anormal event performed on the system, it includes network interfaces used in promiscous mode, process or thread crashing or exiting with ENOMEM error etc.<br />
<br />
The easiest way to use {{ic|aureport}} is :<br />
<br />
# aureport -n<br />
<br />
aureport can be used to generate custom reports, see {{man|8|aureport}}.<br />
<br />
==Which files or syscalls are worth-auditing ?==<br />
Keep in mind that each audit rule added will generate logs, so you must be ready to treat this amount of information.<br />
Basically, each security-related event/file must be monitored, like ids, ips, anti-rootkits etc.<br />
On the other side, it's totally useless to track every write syscall, the smallest compilation will fill your logs with this event.<br />
<br />
More complex set of rules can be set up, performing auditing on a very fine-grained base. If you want to do so, see {{man|8|auditctl}}.<br />
<br />
==Gather logs from different hosts==<br />
The audit framework has a plugin system which provides the possibility to send local logfiles to a remote auditd.<br />
<br />
=== Send logfiles ===<br />
To send your logfiles to a remote host you need the {{ic|audisp-remote}} plugin which comes automatically with the {{Pkg|audit}} package.<br />
Activate the plugin:<br />
{{hc|head=/etc/audisp/plugins.d/au-remote.conf|output=<br />
active = yes<br />
direction = out<br />
path = /usr/bin/audisp-remote<br />
type = always<br />
format = string<br />
}}<br />
<br />
and set the remote host where the logs should be send to:<br />
<br />
{{hc|head=/etc/audisp/audisp-remote.conf|output=<br />
remote_server = domain.name.or.ip<br />
port = 60<br />
##local_port = optional<br />
transport = tcp<br />
}}<br />
<br />
=== Receive logfiles ===<br />
To make audit listen for remote audispds you just need to set the tcp options:<br />
{{hc|head=/etc/audit/auditd.conf|output=<br />
tcp_listen_port = 60<br />
tcp_listen_queue = 5<br />
tcp_max_per_addr = 1<br />
##tcp_client_ports = 1024-65535 #optional<br />
tcp_client_max_idle = 0<br />
}}<br />
<br />
Now you can view the logs of '''all''' configured hosts in the logfiles of the receiving auditd.</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=AppArmor&diff=517973AppArmor2018-04-19T16:01:34Z<p>Phil.r.dubois: /* Kernel */ grammar</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:AppArmor]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|SELinux}}<br />
{{Related|TOMOYO Linux}}<br />
{{Related articles end}}<br />
[[Wikipedia:AppArmor|AppArmor]] is a [[Wikipedia:Mandatory_access_control|Mandatory Access Control]] (MAC) system, implemented upon the [[Wikipedia:Linux_Security_Modules|Linux Security Modules]] (LSM).<br />
<br />
AppArmor, like most other LSMs, supplements rather than replaces the default Discretionary Access Control (DAC). As such it's impossible to grant a process more privileges than it had in the first place. <br />
<br />
Ubuntu, SUSE and a number of other distributions use it by default. RHEL (and its variants) use SELinux which requires good userspace integration to work properly. SELinux attaches labels to all files, processes and objects and is therefore very flexible. However configuring SELinux is considered to be very complicated and requires a supported filesystem. AppArmor on the other hand works using file paths and its configuration can be easily adapted.<br />
<br />
AppArmor proactively protects the operating system and applications from external or internal threats and even zero-day attacks by enforcing a specific rule set on a per application basis. Security policies completely define what system resources individual applications can access, and with what privileges. Access is denied by default if no profile says otherwise. A few default policies are included with AppArmor and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.<br />
<br />
Every breach of policy triggers a message in the system log, and AppArmor can be configured to notify users with real-time violation warnings popping up on the desktop.<br />
<br />
== Installation ==<br />
<br />
=== Kernel ===<br />
<br />
[[Install]] either {{AUR|linux-apparmor}} or {{AUR|linux-hardened-apparmor}}. As a third option you may as well compile the kernel yourself.<br />
<br />
When [[Kernels#Compilation|compiling the kernel]], it is required to at least set the following options:<br />
<br />
CONFIG_SECURITY_APPARMOR=y<br />
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1<br />
CONFIG_DEFAULT_SECURITY_APPARMOR=y<br />
CONFIG_AUDIT=y<br />
<br />
In order to ensure that those new or altered variables do not get overridden, place them at the bottom of the config file or adjust the previous invocations accordingly.<br />
<br />
Instead of setting {{ic|CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE}} and {{ic|CONFIG_DEFAULT_SECURITY_APPARMOR}}, you can also set [[kernel parameters|kernel boot parameters]]: {{ic|1=apparmor=1 security=apparmor}}.<br />
<br />
=== Userspace Tools ===<br />
<br />
The userspace tools and libraries to control AppArmor are supplied by the {{AUR|apparmor}} package.<br />
<br />
The package is a split package which consists of following sub-packages:<br />
<br />
* {{AUR|apparmor}} (meta package)<br />
* {{AUR|apparmor-libapparmor}}<br />
* {{AUR|apparmor-utils}}<br />
* {{AUR|apparmor-parser}}<br />
* {{AUR|apparmor-profiles}}<br />
* {{AUR|apparmor-pam}}<br />
* {{AUR|apparmor-vim}}<br />
<br />
To load all AppArmor profiles on startup, [[enable]] {{ic|apparmor.service}}.<br />
<br />
=== Testing ===<br />
<br />
After a reboot you can test if AppArmor is really enabled using this command as root:<br />
<br />
{{hc|# cat /sys/module/apparmor/parameters/enabled|<br />
Y<br />
}}<br />
<br />
(Y=enabled, N=disabled, no such file = module not in kernel)<br />
<br />
== Disabling ==<br />
<br />
To disable AppArmor for the current session, [[stop]] {{ic|apparmor.service}}, or [[disable]] it to prevent it from starting at the next boot.<br />
<br />
Alternatively you may choose to disable the kernel modules required by AppArmor by appending {{ic|1=apparmor=0 security=""}} to the [[kernel parameters|kernel boot parameters]].<br />
<br />
== Configuration ==<br />
<br />
=== Auditing and generating profiles ===<br />
<br />
To create new profiles using {{ic|aa-genprof}}, {{ic|auditd.service}} from the package {{Pkg|audit}} must be running. This is because Arch Linux adopted systemd and doesn't do kernel logging to file by default. Apparmor can grab kernel audit logs from the userspace auditd daemon, allowing you to build a profile.<br />
To get kernel audit logs, you'll need to have rules in place to monitor the desired application. Most often a basic rule configured with {{man|8|auditctl}} will suffice:<br />
<br />
# auditctl -a exit,always -F arch=b64 -S all -F path=/usr/bin/chromium -F key=MonitorChromium<br />
<br />
but be sure to read [[Audit framework#Adding rules]] if this is unfamiliar to you.<br />
<br />
{{Note|Remember to stop the service afterwards (and maybe clear {{ic|/var/log/audit/audit.log}}) because it may cause overhead depending on your rules.}}<br />
<br />
=== Understanding profiles ===<br />
<br />
Profiles are human readable text files residing under {{ic|/etc/apparmor.d/}} describing how binaries should be treated when executed. A basic profile looks similar to this:<br />
<br />
{{hc|/etc/apparmor.d/usr.bin.test|<br />
#include <tunables/global><br />
<br />
profile test /usr/lib/test/test_binary {<br />
#include <abstractions/base><br />
<br />
# Main libraries and plugins<br />
/usr/share/TEST/** r,<br />
/usr/lib/TEST/** rm,<br />
<br />
# Configuration files and logs<br />
@{HOME}/.config/ r,<br />
@{HOME}/.config/TEST/** rw,<br />
}<br />
}}<br />
<br />
Strings preceded by a '@' symbol are variables defined by abstractions ({{ic|/etc/apparmor.d/abstractions/}}), tunables ({{ic|/etc/apparmor.d/tunables/}}) or by the profile itself. {{ic|#include}} includes other profile-files directly. Paths followed by a set of characters are [http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#File_access_rules access permissions]. Pattern matching is done using [http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#AppArmor_globbing_syntax AppArmor's globbing syntax].<br />
<br />
Most common use cases are covered by the following statements:<br />
<br />
* {{ic|r}} — read: read data<br />
* {{ic|w}} — write: create, delete, write to a file and extend it<br />
* {{ic|m}} — memory map executable: memory map a file executable<br />
* {{ic|x}} — execute: execute file; needs to be preceded by a [http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Execute_rules qualifier]<br />
<br />
Remember that those permission do not allow binaries to exceed the permission dictated by the Discretionary Access Control (DAC).<br />
<br />
This is merely a short overview, for a more detailed guide be sure to have a look at the [http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference documentation].<br />
<br />
=== Parsing profiles ===<br />
<br />
To load (enforce or complain), unload, reload, cache and stat profiles use {{ic|apparmor_parser}}. The default action ({{ic|-a}}) is to load a new profile in enforce mode, loading it in complain mode is possible using the {{ic|-C}} switch, in order to overwrite an existing profile use the {{ic|-r}} option and to remove a profile use {{ic|-R}}. Each action may also apply to multiple profiles. Refer to {{man|8|apparmor_parser|url=http://man.cx/apparmor_parser(8)}} man page for more information.<br />
<br />
== Security considerations ==<br />
<br />
=== Preventing circumvention of path-based MAC via links ===<br />
<br />
This section refers back to outdated kernels and should be considered obsolete. Previously AppArmor can be circumvented via hardlinks in the standard POSIX security model. However, the kernel [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 included] the ability to prevent this vulnerability via the following settings: <br />
<br />
{{hc|/usr/lib/sysctl.d/50-default.conf|2=<br />
...<br />
fs.protected_hardlinks = 1<br />
fs.protected_symlinks = 1}}<br />
<br />
Kernel patches distributed by Ubuntu as workarounds are not needed.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Get desktop notification on DENIED actions ===<br />
<br />
The notify daemon displays desktop notifications whenever AppArmor denies a program access. The script must be started at each boot and needs a few additional parameters:<br />
<br />
# aa-notify -p -f /var/log/audit/audit.log --display $DISPLAY<br />
<br />
The daemon relies on the auditing events being logged to a text file which can be specified using {{ic|-f}}. To circumvent [[systemd]] not logging to a file it is necessary to [[enable]] {{ic|auditd.service}} and pass its log file to {{ic|aa-notify}}. No special auditing rules are necessary for this to work, therefore the overhead is not as significant as it was when [[#Auditing and generating profiles]].<br />
<br />
=== Cache profiles ===<br />
<br />
Since AppArmor has to translate the configured profiles into a binary format it may take some time to load them. Besides being bothersome for the user, it may also increases the boot time significantly!<br />
<br />
To circumvent some of those problems AppArmor can cache profiles in {{ic|/etc/apparmor.d/cache/}}. However this behaviour is disabled by default therefore it must be done manually with {{ic|apparmor_parser}}. In order to write to the cache use {{ic|-W}} (overwrite existing profiles with {{ic|-T}}) and reload the profiles using {{ic|-r}}. Refer to [[#Parsing profiles]] for a brief overview of additional arguments.<br />
<br />
== See also ==<br />
<br />
* [http://wiki.apparmor.net/ AppArmor wiki]<br />
* [http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference AppArmor Core Policy Reference] — Detailed description of available options in a profile<br />
* [http://ubuntuforums.org/showthread.php?t=1008906 Ubuntu Tutorial] — General overview of available utilities and profile creation<br />
* [https://help.ubuntu.com/community/AppArmor Ubuntu Wiki] — Basic command overview<br />
* [http://wiki.apparmor.net/index.php/AppArmor_versions AppArmor Versions] — Version overview and links to the respective release notes<br />
* {{man|5|apparmor.d|url=http://manpages.ubuntu.com/manpages/artful/man5/apparmor.d.5.html}} — Structure of the AppArmor configuration directory<br />
* {{man|8|apparmor_parse|url=http://manpages.ubuntu.com/manpages/artful/man8/apparmor_parser.8.html}} — The most fundamental AppArmor utility to load, unload, cache and stat profiles<br />
* [http://wiki.apparmor.net/index.php/Kernel_interfaces Kernel Interfaces] — Low level interfaces to the AppArmor kernel module<br />
* [https://wiki.ubuntu.com/ApparmorProfileMigration Apparmor Profile Migration] — Emergence of profiles<br />
* [[wikipedia:Linux Security Modules]] — Linux kernel module on which basis AppArmor is build upon<br />
* [https://launchpad.net/apparmor Launchpad Project Page]<br />
* {{Bug|21406}} — Initial discussion about the introduction of AppArmor</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Kernel&diff=517919Kernel2018-04-19T05:53:10Z<p>Phil.r.dubois: /* Other patchsets */ added AppArmor to list of kernels</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 (operating_system)|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 stable [[Wikipedia:Linux kernel|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 />
== Officially supported ==<br />
<br />
*{{App|[https://www.kernel.org/category/releases.html Stable]|Vanilla Linux kernel and modules, with a few patches applied.|https://www.kernel.org/|{{Pkg|linux}}}}<br />
<br />
*{{App|[https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project Hardened]|A security-focused Linux kernel applying a set of 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]].|https://github.com/copperhead/linux-hardened|{{Pkg|linux-hardened}}}}<br />
<br />
*{{App|[https://www.kernel.org/category/releases.html Longterm]|Long-term support (LTS) Linux kernel and modules.|https://www.kernel.org/|{{Pkg|linux-lts}}}}<br />
<br />
*{{App|[https://github.com/zen-kernel/zen-kernel ZEN Kernel]|Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems. Some more details can be found on https://liquorix.net (which provides kernel binaries based on ZEN for Debian).|https://github.com/zen-kernel/zen-kernel|{{Pkg|linux-zen}}}}<br />
<br />
== Compilation ==<br />
Arch Linux provides two methods of kernel compilation.<br />
<br />
=== Using Arch Build System ===<br />
<br />
Takes advantage of the high quality of existing {{Pkg|linux}} [[PKGBUILD]] and the benefits of [[Wikipedia:Package management system|package management]].<br />
<br />
See [[Kernels/Arch Build System]].<br />
<br />
=== Traditional ===<br />
<br />
This involves manually downloading a source tarball, and compiling in your home directory as a normal user.<br />
<br />
See [[Kernels/Traditional compilation]].<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 />
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 />
===Major patchsets===<br />
<br />
{{Warning|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 />
*{{App|[[Linux-ck]]|Contains patches by Con Kolivas designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload.|http://ck.kolivas.org/patches/|{{AUR|linux-ck}}}}<br />
<br />
*{{App|[https://pfactum.github.io/pf-kernel/ pf-kernel]|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. The most prominent patches of linux-pf are PDS CPU scheduler and UKSM.|https://pfactum.github.io/pf-kernel/|Packages:}}<br />
:*[[Unofficial_user_repositories#post-factum_kernels|Repository]] by pf-kernel developer, [https://aur.archlinux.org/account/post-factum post-factum]<br />
:*[[Unofficial_user_repositories#home-thaodan|Repository]], {{AUR|linux-pf}}, {{AUR|linux-pf-preset-default}}, {{AUR|linux-pf-lts}} by pf-kernel fork developer, [https://aur.archlinux.org/account/Thaodan Thaodan]<br />
<br />
*{{App|[[Realtime kernel]]|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.|https://wiki.linuxfoundation.org/realtime/start|{{AUR|linux-rt}}, {{AUR|linux-rt-lts}}}}<br />
<br />
=== Other patchsets ===<br />
<br />
Some of the listed packages may also be available as binary packages via [[Unofficial user repositories]].<br />
<br />
*{{App|AppArmor|The [[Wikipedia:Mandatory_access_control|Mandatory Access Control]] (MAC) system, implemented upon the [[Wikipedia:Linux_Security_Modules|Linux Security Modules]] (LSM).|[[AppArmor]]|{{AUR|linux-apparmor}}, {{AUR|linux-hardened-apparmor}}}}<br />
<br />
*{{App|Aufs|The aufs-compatible linux kernel and modules, useful when using [[docker]].|http://aufs.sourceforge.net/|{{AUR|linux-aufs_friendly}}}}<br />
<br />
*{{App|BLD|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.|https://github.com/rmullick/bld-patches|{{AUR|linux-bld}}}}<br />
<br />
*{{App|Git|Linux kernel and modules built using sources from Linus Torvalds' Git repository|https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git|{{AUR|linux-git}}}}<br />
<br />
*{{App|Libre|The Linux Kernels without "binary blobs".|https://www.fsfla.org/ikiwiki/selibre/linux-libre/|{{AUR|linux-libre}}}}<br />
<br />
*{{App|Liquorix|Kernel replacement built using 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.|https://liquorix.net|{{AUR|linux-lqx}}}}<br />
<br />
*{{App|Longterm 4.4|Long-term support (LTS) Linux 4.4 kernel and modules.|https://www.kernel.org/|{{AUR|linux-lts44}}}}<br />
<br />
*{{App|Mainline|The Mainline Linux Kernel and modules.|https://www.kernel.org/|{{AUR|linux-mainline}}}}<br />
<br />
*{{App|MultiPath TCP|The Linux Kernel and modules with Multipath TCP support.|https://multipath-tcp.org/|{{AUR|linux-mptcp}}}}<br />
<br />
*{{App|[[Reiser4]]|Successor filesystem for ReiserFS, developed from scratch by Namesys and Hans Reiser.|https://sourceforge.net/projects/reiser4/files/|}}<br />
<br />
*{{App|VFIO|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.|https://lwn.net/Articles/499240/|{{AUR|linux-vfio}}, {{AUR|linux-vfio-lts}}}}<br />
<br />
== See also ==<br />
<br />
* [http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (free ebook)</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Talk:Security&diff=517917Talk:Security2018-04-18T23:31:58Z<p>Phil.r.dubois: /* Improving the password section */ link to http site for testing password entropy???</p>
<hr />
<div>==Todo==<br />
*Update "Lockout user after three failed login attempts", file mentioned no longer contains those lines ? <br />
*descriptions/rationale for all the links to other articles (MAC)<br />
*base64 /dev/urandom | dd bs=1 count=10 2>/dev/null<br />
*use (enhanced?) ACL on partitions<br />
*[[Disk quota|quotas]]<br />
*limits/cgroups<br />
*sudo timeout<br />
*DNSSEC<br />
*[[Securely Wipe HDD]]<br />
*[[Using File Capabilities Instead Of Setuid]]<br />
*VNC, proxies, ssl, etc<br />
*rvim/rgvim<br />
*browser security (requestpolicy, noscript, sand-boxing browser)<br />
*PAX/<s>grsecurity</s><br />
*stack protector gcc flag: Put some text in the page indicationg Archlinux has it by default (See: [https://bugs.archlinux.org/task/18864 FS#18864])<br />
* run services as non-root (mention that Arch does this where possible by default - but it needs improvement via feature requests)<br />
* run services in clean namespaces<br />
* run services in chroots<br />
* mention issues with sudo (any X11 application can grab the password, and it is a large setuid binary with potential vulnerabilities)<br />
* describe password expiry policies (chage, passwd -X, etc.)<br />
--[[User:Thestinger|thestinger]] 18:09, 11 January 2011 (EST), --[[User:Det|Det]] ([[User talk:Det|talk]]) 11:35, 3 January 2013 (UTC),<br />
--[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 13:49, 19 April 2013 (UTC)<br />
-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:45, 12 August 2013 (UTC)<br />
<br />
== CentOS Wiki OS Protection Article ==<br />
<br />
Hello,<br />
<br />
This seems to be a good article to cross-reference or to use as a basis to pull in more content here. CC BY SA rights so I suspect it is compatible with the Arch Wiki. http://wiki.centos.org/HowTos/OS_Protection<br />
<br />
I am hoping to pull some content in myself, but I am by no means a security guy. I figured some wiser heads might be able to make better use of it than I or correct any mistakes I might make while attempting to contribute.<br />
<br />
Cheers,<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 22:29, 1 August 2013 (UTC)<br />
<br />
:Of course the information itself is not licensed/licenseable, however the way it is presented is, so you either study the original article and present the same information here in an original way, or you actually adapt some content from that article, but in that case the licence clearly states that you have to credit the original authors, and ''I guess'' you can do it by mentioning the original article in the Summary of your edits, and adding a link to [[Security#See also]].<br />
:Just as a clarification, I know that [[Help:Style#Hypertext metaphor]] states "If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information", however in this case we can't talk about "upstream documentation", that's why the rule doesn't apply and duplication of information is allowed, being CentOS's and Arch's wikis on the "same level" with respect to the information provided.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:33, 3 August 2013 (UTC)<br />
<br />
:: Let's first compare the sections in the two articles and see how they relate:<br />
::* '''Modifying fstab''' -> [[Security#Partitions]].<br />
::* '''Package installs''' -> We have [[Security#Authenticating_packages]] and a note at the bottom of [[Security#Partitions]].<br />
::** We ''definitely'' should talk about [[Pacman#Package_security]] in more depth. That is, we should have a general overview of the function of [[Pacman-key]] and why it is important from a security perspective. [[Pacman-key]] mentions the function of the utility, but not its importance from a security perspective.<br />
::* '''Physical protection''' -> [[Security#Physical_security]]<br />
::* '''Restricting root''' -> We have [[Security#Use_sudo_instead_of_su]] which is a good start, but does not mention [[Ssh#Deny_root_login]]. File system permissions on {{ic|/root}}, which I think by default are not {{ic|700}} (they should be) should be added to [[Security#Filesystem permissions]].<br />
::* '''Umask restrictions''' -> We should talk about {{ic|umask}} in [[Security#Filesystem permissions]].<br />
::* '''Pam modifications''' -> [[Realtime process management]], a wiki page in desperate need of editing.<br />
::* '''Reaping idle users''' -> We should cover this in [[Security#User_setup]].<br />
::* '''Restricting cron and at''' -> We have no equivalent.<br />
::* '''Wireless has to go''' -> Maybe worth talking about, but this is low-priority unless we are willing to write a more detailed section called "Wireless security" that is about more than just "turn off wireless."<br />
::* '''Sysctl Security''' -> Covered in [[Sysctl#TCP/IP stack hardening]], maybe we should just link to this.<br />
::* '''Using TCP Wrappers''' -> I could not find anything on ArchWiki discussing general security practices for {{ic|/etc/hotss}}.<br />
::* '''Beefing up IPTables''' -> Should be adapted into [[Iptables]], but perhaps [[Simple Stateful Firewall]] (an article that has good information, but I am not sure if its name makes sense).<br />
::* '''Tamper Resistance''' -> We should have a section on '''logging''' in general and incorporate tools like this, probably.<br />
::Comments ''highly'' appreciated.<br />
::-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 05:09, 3 August 2013 (UTC)<br />
:::If you want to start working in this direction, go for it! :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 5 August 2013 (UTC)<br />
<br />
== Grsecurity sections ==<br />
<br />
We now have three sections devoted only to Grsecurity. What can we do about this?<br />
<br />
The [https://wiki.archlinux.org/index.php?title=Security&diff=272330&oldid=272327 addition] of [[Security#Grsecurity RBAC]] seems to be redundant. However, I agree that "RBAC" is a better name for Grsecurity's MAC implementaiton than [[Security#Access Control Lists]]. In technical terms ACLs are a subset of RBAC and Grsecurity implmeents both. The Grsecurity patchset [https://www.cs.virginia.edu/~jcg8f/GrsecuritySELinuxCaseStudy.pdf only had ACLs][PDF] back in 2005, and the cited case study mentions (it also refers to SELinux as a RBAC implementation, so perhaps SELinux should also be mentioned there):<br />
<br />
:This implementation of ACLs creates a form of process-based mandatory access control. It is possible to restrict what a process can and cannot do. Additionally, access can be restricted to an object for any user, even root. Further, these restrictions cannot be changed by normal users. The system will soon offer role-based access control as well. <br />
<br />
Probably the right solution for this is:<br />
<br />
* Rename [[Security#Grsecurity RBAC]] to [[Security#Role-Based Access Control]].<br />
* Discuss both SELinux/Grsecurity implementations there. There is no need for the RBAC section to be Grsecurity-specific.<br />
<br />
[[Security#Kernel Hardening]] is only about [[Grsecurity]] but I am not sure if it should be merged into [[Security#Mandatory access control|Mandatory access control]] as suggested.<br />
<br />
* I think it is best to give general recommendations here rather than something like "install Grsecurity to make your kernel secure".<br />
* The right solution is probably to expand [[Security#Kernel Hardening]] and discuss [[Wikipedia:PaX]] and whatnot more generally, mentioning Grsecurity as an implementation. <br />
* I do think [[Security#Kernel Hardening]] should probably be moved lower on the page, closer to [[Security#Mandatory access control]]/[[Security#Network and Firewalls]]/[[Security#Authenticating packages]] since that seems to better suit the logical flow of the article.<br />
<br />
-- [[User:Ndt|Ndt]] ([[User Talk:Ndt|talk]]) 21:36, 4 September 2013 (UTC)<br />
<br />
:I can't comment on the content since I don't know much about it, but allow me to add some notes:<br />
:# The different security models (RBAC, MAC, DAC, ACL, ...) should be compared/described separately from the individual implementations (SELinux, Tomoyo, AppArmor, ...). Meaning there should be separate sections for each group, but mainly ''"RBAC is significantly faster then SELinux."'' does not make much sense.<br />
:# There should always be provided alternatives, not just 1:1 mapping (like in case of RBAC and Grsecurity).<br />
:# Descriptions of both ''groups'' can be provided from multiple perspectives. From my experience, in these situations a comparison table is often the best solution.<br />
:I'm not sure about the [[Security#Kernel Hardening]] section, should it focus only on security options that require patching the Arch kernel, or also those included in Arch kernel but not activated?<br />
:I hope it makes sense...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:09, 4 September 2013 (UTC)<br />
::+1, also on mentioning the other options. I further agree with Ndt, moving [[Security#Kernel Hardening]] down to below (or above?) [[Security#Mandatory_access_control]] and merging the bits for [[Security#Kernel_parameters]] into it is better flow, then any other options that are avail without patching into it, followed by PAX and the existing Grsecurity so those get mentioned just before MAC. If someone wants to work on that: I like the comparison/table [http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html here] maybe it gives some inspiration how to expand. If not, maybe good for See also. (further comparisons are at the bottom of the link). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:05, 5 September 2013 (UTC)<br />
<br />
== Nobody as script user ==<br />
<br />
[[Systemd/cron_functionality#The_pkgstats_service]] article says that it is better to use {{ic|noboby}} for some tipe of scripts. Is there any person who can explain further and add a note in this article?<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:29, 13 September 2013 (UTC)<br />
<br />
: Following the [[Wikipedia:Principle of least privilege|principle of least privilege]] it is logical to run as many scripts as possible as an unprivileged user. But this is not possible always, e.g. when the script needs (write) access to some file(s) to function properly, you need to provide those privileges. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:32, 13 September 2013 (UTC)<br />
::It's not actually a good idea to do this. Processes running as {{ic|nobody}} can ptrace each other, so there is a loss of security if more than one thing is run as that users. Ideally, individual users would be created for each case. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 10:52, 31 March 2014 (UTC)<br />
<br />
== Improving the password section ==<br />
<br />
This is a call for ideas and community effort to improve the password recommendations here. I think it's generally agreed that the password section needs (and has, for a long time, needed) some work.<br />
<br />
What does the password section need? Is it even necessary - does it make sense for someone to get this information from a wiki? How can we back up our statements, so that we know that the password recommendations made aren't just totally arbitrary (e.g, "at least one number ...")? <br />
<br />
Citing sources, I think, is useful here - even though there's an element of password generation that is a matter of opinion, there are many recommendation that can be made that are ''not'' opinion. Just my two cents. - [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 21:51, 29 August 2014 (UTC)<br />
<br />
:A part I question is: <br />
<br />
::''Insecure passwords include... Phrases of known words (e.g., all of the lights, correct horse battery staple), even with character substitution.''<br />
<br />
:How about [http://world.std.com/~reinhold/diceware.html Diceware] (mentioned in [[Disk_encryption#Choosing_a_strong_passphrase]], which is linked to at the end of the section) ? --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:48, 31 August 2014 (UTC)<br />
<br />
::I've added some clarifications to that sentence: [https://wiki.archlinux.org/index.php?title=Security&diff=333453&oldid=333379].<br />
::The whole problem comes down to the bits of entropy of a passphrase: if calculated against brute-force attacks, every character from the chosen set counts, because in general they are not releated to each other. In case of Diceware, the characters inside each word ''are'' related to each other, and instead what is independent are the words themselves, so the bits must be calculated on a per-word basis (it's vulnerable to dictionary attacks, which can be seen as a form of brute-force attack with every word representing a character in a set of 7776). Now, as you can see from the table in [[Wikipedia:Password strength]], a set of 5 Diceware words is equal to e.g. 10 ASCII characters (64 bits); 7 words == 13 ASCII. Nowadays you'd need more than that to be "safe", but in the end it mostly depends on the importance of what you want to protect. Of course if you choose a phrase of words that are also grammatically related with each other, you're exposing it to some smart dictionary attacks, which would further lower the total bits of entropy.<br />
::Actually, that whole section could be questioned, in fact I could make a strong password even with "Root words or common strings followed or preceded by added numbers, symbols, or characters", if I chose enough "root words" and numbers; I could even make a strong password with dictionary words grammatically related, if the sentence was long enough :) I hope it makes it clearer.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:34, 1 September 2014 (UTC)<br />
<br />
:::Thanks for clarifying. Maybe add [[Wikipedia:Password strength]] to the article (it's already linked in [[Wikipedia:Password_cracking]], but it wouldn't hurt here)? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 01:32, 2 September 2014 (UTC)<br />
<br />
::::Link added after merging [[Disk_encryption#Choosing_a_strong_passphrase]]. Still, the whole section is very unorganized :( but at least now all the info is gathered in one place. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:16, 3 September 2014 (UTC)<br />
<br />
:::::First time I ever edit or contribute to a Wiki. I added an example of enforcing a password policy using pam_cracklib [[User:Redsolja|Redsolja]] ([[User talk:Redsolja|talk]]) 15:48, 26 April 2015 (UTC)<br />
<br />
::::::Thank you, very well done for a first edit! — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:34, 27 April 2015 (UTC)<br />
<br />
:In the Choosing secure passwords section, I'd like to point out that we're linking to an unencrypted webpage for testing password entropy... [[User:phil.r.dubois|phil.r.dubois]] ([[User talk:phil.r.dubois|talk]]) 23:30, 18 April 2018 (UTC)<br />
<br />
== Removal of incorrect warning ==<br />
<br />
:''Moved from [[User_talk:thestinger]].'' -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:01, 25 February 2015 (UTC)<br />
<br />
Greetings, I have removed [https://wiki.archlinux.org/index.php?title=Security&diff=307743&oldid=307742 the warning] regarding SHA512 on the password hashing section. It's true that one shouldn't use plain sha512 for password hashing, but that isn't what arch (or other Linux distributions) use or are even able to use. What they call "sha512" is crypt_sha512, analogous to cryptmd5 but with the hash function replaced. Crypt_sha512 is a strong sequential function with a configurable iteration parameter. Normal configurations are fairly slow by default and are configurable to be arbritarily slow. I also updated the text to make it clear that it used an iterated sha512 so that others would be less likely to suffer from your confusion. Cheers. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 23:39, 24 December 2014 (UTC)<br />
<br />
:I was fully aware that it runs a configurable number of sha512 iterations when I made the change. It's not enough iterations to make up for how cheap it is relative to bcrypt/scrypt and it requires very little memory so it does nothing to counter doing billions of hashes per second on a GPU. I don't care enough to argue about it but you shouldn't assume that it had anything to do with confusion. -- [[User:thestinger|thestinger]] 23:48, 24 December 2014 (UTC)<br />
<br />
::Reverted OP's removal a while ago, so this can be closed. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:23, 19 January 2015 (UTC)<br />
<br />
:::It may not be wrong, but it’s still misleading, and conflicts with the immediately following paragraph. Is there a nice way to change each to satisfy everyone? -- [[User:Charmander|Charmander]] ([[User talk:Charmander|talk]]) 19:12, 19 January 2015 (UTC)<br />
<br />
:: I have rephrased the first sentence of the following paragraph to "''The default Arch hash [[SHA_password_hashes|sha512]] is, however, different than plain SHA512. It is very strong and there is no need to change it.''" in an attempt to remove the inconsistency. Please proof-read this, since I am a no cryptography expert - the '''only''' source I was using was this very discussion. Also I am not native to English, so I can't guarantee I was grammatically correct. Here is the diff to my edit: [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393653&oldid=383265] [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:30, 24 August 2015 (UTC)<br />
<br />
::: I don't understand what this changes - how is the SHA512 sum ''different'' (considering thestinger's argument above) ? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:36, 24 August 2015 (UTC)<br />
<br />
:::: AFAIK the Arch's SHA512 iterates, while plain SHA512 doesn't? Anyway, if what I wrote is wrong, please revert it. But if you do, please do fix the inconsistency in a more competent way. The original phrasing is misleading and just cannot last any more. [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 20:42, 24 August 2015 (UTC)<br />
<br />
::::: See [https://wiki.archlinux.org/index.php?title=Security&diff=393663&oldid=393653]. Perhaps we should also add how the number of iterations could be increased (maximum is 999 999 999, according to man passwd). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:49, 24 August 2015 (UTC)<br />
<br />
:::::: Added with [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393665&oldid=393663]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:56, 24 August 2015 (UTC)<br />
:::::: edit: going to undo this since I don't know what's meant above with "not enough". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:57, 24 August 2015 (UTC)<br />
<br />
::::::: One more thing. Your phrasing does not state whether or not these 5000 iterations, in association with storing passwords in /etc/shadow, actually are secure. With the nearby warning, an impression is made that in might not be enough and that the wiki advises the user to use something else. You have removed this important sentence: "''It is very strong and there is no need to change it''". If this is appropriate, could you kindly explicitly state whether or not this default Arch's hashing is considered secure enough for normal desktop use? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:00, 24 August 2015 (UTC)<br />
<br />
:::::::: I'm not the expert, but I'd assume 5000 iterations is "not enough". However I don't know if 999 999 999 or any arbitray high amount is "enough" either. This assessment likely changes as hardware gets more powerful, or more efficient methods are discovered.<br />
:::::::: The fact that the hashes are stored in {{ic|/etc/shadow}} should be sufficient, but I don't know how to accurately word that ("can't be copied or cracked" is vague at best). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:05, 24 August 2015 (UTC)<br />
<br />
::::::::: I'm honestly unsure if I'm nitpicking or if this is a serious problem. Anyway I [https://wiki.archlinux.org/index.php?title=Security&type=revision&diff=393676&oldid=393670 have put] a Template:Expansion. Hope that's OK? [[User:Kmph|Kmph]] ([[User talk:Kmph|talk]]) 21:23, 24 August 2015 (UTC)<br />
<br />
:::::::::: Sure, thanks. :) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:02, 24 August 2015 (UTC)<br />
<br />
:::::::::::I have practically rewritten the section with [https://wiki.archlinux.org/index.php?title=Security&diff=410426&oldid=409966 these 3 edits], adding lots of links so that people can try to better understand this complicated process.<br />
:::::::::::Functions like bcrypt and scrypt are indeed aimed at making it more expensive to brute-force passwords with custom-hardware attacks, but if we don't tell people how to ''decide'' what function to use, and how to ''set'' it up, a warning like that is only FUD...<br />
:::::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:29, 28 November 2015 (UTC)<br />
<br />
== Let's forget about limits.conf? ==<br />
<br />
Look rapidly at [https://sskaje.me/systemd-ulimit/ this] blog post.<br />
<br />
In short: '''limits.conf is useless''' for systemd daemons, because systemd has it's own ''LimitNOFILE=123456'', ''LimitETC=50K''.<br />
<br />
This is also an issue for desktop users, because users implemented via slices, services and User Manager.<br />
<br />
To set per-user resource-limits, now do the following:<br />
<pre><br />
mkdir -p /etc/systemd/system/user@1000.service.d/<br />
cat > /etc/systemd/system/user@1000.service.d/limits.conf << EOF<br />
[Service]<br />
LimitNFILE=131072<br />
EOF<br />
systemd daemon-reload<br />
systemd restart user@1000<br />
</pre><br />
<br />
'''1000''' -- is a user's uid. Optional.<br />
<br />
The archwiki is full of useless limits.conf documentation, it is time to update it, or i've missing something? [[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 09:51, 16 December 2015 (UTC)<br />
<br />
:: Oops, looks like all this info valid only for dbus-activated user apps like gnome-terminal.<br />
::[[User:Shahid|Shahid]] ([[User talk:Shahid|talk]]) 14:14, 16 December 2015 (UTC)<br />
<br />
== pam_tally ==<br />
<br />
According to the PAM SAG pam_tally is deprecated and should be replaced by pam_tally2. I suggest to update the page accordingly. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 20:20, 7 February 2016 (UTC)<br />
<br />
:Is the information in the manpage for pam_tally2 accurate? I don't know PAM, and I'm not fully comfortable with changing the page without asking first. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 00:01, 18 June 2016 (UTC)<br />
<br />
::Good you ask, such should indeed be tested before updating. Please check [https://bugs.archlinux.org/task/42120#comment148179] as input when you go about changing the section. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:58, 18 June 2016 (UTC)<br />
<br />
:::If pam_tally2 is going to be deprecated soon anyway in favour of pam_faillock, then updating the page right now seems a bit pointless. [[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 11:28, 18 June 2016 (UTC)<br />
<br />
::::Well, the faillock module has not landed in the package for years, that part remains to be seen. Updating is useful I think, because due to the nature of the pam project they rarely remove modules (since that can severly break existing installations). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:40, 19 June 2016 (UTC)<br />
<br />
::I've run into a couple of problems:<br />
::#pam_tally, the original one, seems to have a default configuration in place, and I'm not sure what steps are needed to completely disable it. Is it enough to remove its line from {{ic|/etc/pam.d/system-login}}, or is there something more to be done? <br />
::#In [https://bugs.archlinux.org/task/42120#comment148179] it's mentioned that pam_tally2 should be added to account pam_tally2.so in the stack as well, but I don't know this should be done. I've gathered that I need to add the line {{ic|account required pam_tally2.so}} to some account section somewhere, but I don't know which file specifically I should be editing.<br />
::I would suggest that this be left to someone who has a better understanding of how PAM works. --[[User:Crashlog|Crashlog]] ([[User talk:Crashlog|talk]]) 16:37, 21 June 2016 (UTC)<br />
<br />
== Using systemd for more secure services ==<br />
<br />
I saw [https://lwn.net/SubscriberLink/709755/a3b534d94fc57157/ this article] that lists several options for systemd units to help protect one's system. I think some of these should be added to our article. In particular {{man|5|systemd.exec}} recommends setting/enabling {{ic|ProtectHome}}, {{ic|ProtectSystem}}, {{ic|ProtectKernelTunables}}, {{ic|ProtectControlGroups}}, {{ic|RestrictRealtime}} for most long-running services. Some of these are simple boolean options. Others have different levels that can be set. Lennart lists these and others [https://lwn.net/Articles/709764/ here]. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 19:40, 3 January 2017 (UTC)<br />
:Working on a draft of some ideas here: [[User:Rdeckard/Secure Systemd]] -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 14:10, 5 January 2017 (UTC)<br />
<br />
== grsecurity End of Support ==<br />
<br />
There was a proposal to archive, I think this is a mistake until we know more about how this shakes out. There have been some rumblings that Gentoo Hardened may take over primary development of a branch of the 3.1 patchset. Alternatively, I've already reached out to the Grsecurity team to ask about individual licensing. As Arch is an open source community, it's not unreasonable that there could be some very reasonable individual license. If so, we could probably move the package to the AUR, and users would need to buy a license.<br />
<br />
Finally, the last released patch was for 4.9, which is a stable kernel branch -- there's no reason to kill the wiki just yet, as 4.9 will not be EOL for a long time.<br />
<br />
[[User:Osteichthyes|Osteichthyes]] ([[User talk:Osteichthyes|talk]]) 23:56, 27 April 2017 (UTC)<br />
<br />
:3.1 doesn't work on Arch since systemd requires at least 3.14 or higher, and I somehow doubt that the Arch developers or TUs are willing to cash out for a grsecurity license. Regarding the stance on 4.9, see this post by the maintainer: https://lists.archlinux.org/pipermail/arch-general/2017-April/043612.html {{Unsigned|19:05, 27 April 2017|Alad}}<br />
<br />
::There's a gradm ABI version included in the version, but it doesn't have the importance that they think it does. The grsecurity version is the kernel version + the grsecurity timestamp. That 3.1 version is only relevant to RBAC / gradm, and RBAC certainly has a lot of improvements without that version changing since I think it's only for breaking changes to the ABI. -- [[User:thestinger|thestinger]] 16:22, 29 April 2017 (UTC)<br />
<br />
:If things change and grsecurity is available in some form to Arch Linux users, I don't think it would be hard to resurrect the page (or parts of it) from the archive. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 23:33, 28 April 2017 (UTC)<br />
<br />
:There isn't going to be individual licensing. If someone takes over maintenance, it needs to be renamed from PaX and grsecurity so there will need to be a new name for this page and a bunch of configuration and tool naming may end up being updated to match the new name if it's a true fork with active development. Maintaining the 4.9 patch is a dead end and if that's all that happens, it's over. Either way, I'm not maintaining it anymore including paxd and the exceptions being a dead project. I saw this coming for a long time, so I haven't been putting much work into it for a while and now it's over. The most I'll consider is a package enabling the Kernel Self Protection Project features... which is such a tiny portion of what was provided. Key features like RAP are going to be unavailable for 5+ years if they even land at all. -- [[User:thestinger|thestinger]] 16:17, 29 April 2017 (UTC)<br />
<br />
<br />
== Kernel hardening - disabling jit compiler ==<br />
<br />
Currently, this page advises to disable bpf jit compiler by setting ''net.core.bpf_jit_enable'' to 0. Doing so causes error:<br />
<pre><br />
$ sudo sysctl -w net.core.bpf_jit_enable=0 <br />
sysctl: setting key "net.core.bpf_jit_enable": Invalid argument<br />
net.core.bpf_jit_enable = 0<br />
</pre><br />
This commit in the linux repo from January seems to indicate that disabling the jit compiler is not longer possible (or desirable): [https://github.com/torvalds/linux/commit/290af86629b25ffd1ed6232c4e9107da031705cb commit on Github torvalds/linux]. There is however a ''net.core.bpf_jit_harden'' flag available. I do not have the necessary knowledge to decide on what the best course of action is and edit the pages. Should the ''Keep BPF JIT compiler disabled'' section be removed? Is the''bpf_jit_harden'' flag advisable? [[User:Gthau|Gthau]] ([[User talk:Gthau|talk]]) 18:34, 26 March 2018 (UTC)</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Security&diff=517916Security2018-04-18T23:19:28Z<p>Phil.r.dubois: /* Choosing secure passwords */ appearance of Wikipedia link</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 [[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 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|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]]).<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 />
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 {{man|8|pam_cracklib}} and {{man|8|pam_unix}} 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 />
!Partition<br />
!{{ic|nodev}}<br />
!{{ic|nosuid}}<br />
!{{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 />
=== 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 after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}} to read as:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=#%PAM-1.0<br />
<br />
auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed<br />
account required pam_tally2.so<br />
}}<br />
<br />
pam_tally is deprecated and superseded by pam_tally2, so you will want to comment out the pam_tally line:<br />
<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<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 --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 />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq -c}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] often is considered as insecure. Thus it is recommended to avoid running Xorg as root, like it is usually the default configuration.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run Xorg sessions without root privileges for Xorg process.<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#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 />
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 />
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'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 />
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=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 />
{{Warning|This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).}}<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 user sessions to work correctly, 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 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 />
[[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 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 />
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 Security 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 />
=== Protect against rogue USB devices ===<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 />
* [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://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]<br />
* [https://archive.fo/wrjIM UNIX and Linux Security Checklist v3.0]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=517691Dnscrypt-proxy2018-04-16T21:39:08Z<p>Phil.r.dubois: /* Unbound */ do-not-query-localhost should be within the server section, but the forward-zone starts a new section</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
{{Out of date|Version 1.x of the dnscrypt-proxy client documented below has reached EOL. See {{Bug|57027}}. It has been superseded by {{Pkg|dnscrypt-proxy}} version 2 which is a new implementation of the same protocol.}}<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
{{Tip|{{AUR|dnscrypt-proxy-gui}} provides a GUI written in Qt to set the DNS server used by DNSCrypt.}}<br />
<br />
== Configuration ==<br />
<br />
{{Tip|An example configuration file, {{ic|/etc/dnscrypt-proxy.conf.example}} is provided, but note that systemd overrides the {{ic|LocalAddress}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
<br />
Select a resolver from {{ic|/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv}} and edit {{ic|/etc/dnscrypt-proxy.conf}}, using a short name from the csv file's first column, {{ic|Name}}. For example, to select ''dnscrypt.eu-nl'' as the resolver:<br />
<br />
ResolverName dnscrypt.eu-nl<br />
<br />
{{Tip|<br />
* A potentially more up-to-date list is available directly on the [https://github.com/dyne/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv upstream page].<br />
* At this stage you may also wish to add an unprivileged user to run dnscrypt. See [[#dnscrypt runs with root privileges]].}}<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. Ensure that {{ic|LocalCache on}} is in your dnscrypt configuration file to enable this feature.}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
This can be combined with the additions in [[#dnscrypt runs with root privileges]].<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Router&diff=517543Router2018-04-15T04:29:47Z<p>Phil.r.dubois: /* Persistent interface naming */ grammar</p>
<hr />
<div>[[Category:Network sharing]]<br />
[[Category:Security]]<br />
[[Category:Firewalls]]<br />
[[ja:ルーター]]<br />
[[zh-hans:Router]]<br />
This article is a tutorial for turning a computer into an internet gateway/router. To strengthen its security it should not run '''any''' services available to the outside world. Towards the LAN, run only gateway specific services especially do not run httpd, ftpd, samba, nfsd, etc. as those belong on a server in the LAN since they introduce security risks.<br />
<br />
This article does not attempt to show how to set up a shared connection between 2 PCs using cross-over cables. For a simple internet sharing solution, see [[Internet sharing]].<br />
<br />
{{Note|Throughout the article '''intern0''' and '''extern0''' are used as names for the network interfaces. The reasoning is further explained in [[#Persistent interface naming]].}}<br />
<br />
==Hardware Requirements==<br />
* At least 1 GB of hard drive space. The base install will take up around 500MB of space and if you want to use a caching web proxy, you will need to reserve space for the cache as well.<br />
* At least two physical network interfaces: a gateway connects two networks with each other (actually router can be made using single physical interface that underlay two VLAN interfaces and connected to VLAN-aware switch, so-called router-on-a-stick configuration, but it is not covered in this article). You will need to be able to connect those networks to the same physical computer. One interface must connect to the external network, while the other connects to the internal network.<br />
* A hub, switch or UTP cable: You need a way to connect the other computers to the gateway<br />
<br />
==Network interface configuration==<br />
<br />
===Persistent interface naming===<br />
Systemd automatically chooses unique interface names for all your interfaces. These are persistent and will not change when you reboot. <br />
However you might want to rename your interfaces e.g. in order to highlight their different networks to which they connect. In the following sections of this guide the below stated convention is used throughout:<br />
<br />
* '''intern0''': the network card connected to the LAN. On an actual computer it will probably have the name enp2s0, enp1s1, etc.<br />
* '''extern0''': the network card connected to the external network (or WAN). It will probably have the name enp2s0, enp1s1, etc.<br />
<br />
You may change the assigned names of your devices via a configuration file using [[Systemd-networkd]] described in [[Systemd-networkd#Renaming an interface]] or by a [[udev]]-rule following [[Network configuration#Change device name]]. Due to the example-rich nature of this article you might want to choose the above described names.<br />
<br />
===IP configuration===<br />
Now you will need to configure the network interfaces. The best way to do so is using [[netctl]] profiles. You will need to create two profiles.<br />
{{Note|If you will be connecting to the Internet only via PPPoE (you have one WAN port) you '''do not need''' to setup or enable the extern0-profile. See below for more information on configuring PPPoE.}}<br />
* {{ic|/etc/netctl/extern0-profile}}<br />
Description='Public Interface.'<br />
Interface=extern0<br />
Connection=ethernet<br />
IP='dhcp'<br />
<br />
* {{ic|/etc/netctl/intern0-profile}}<br />
Description='Private Interface'<br />
Interface=intern0<br />
Connection=ethernet<br />
IP='static'<br />
Address=('10.0.0.1/24')<br />
<br />
{{Note|The example configuration above assumes a full subnet. If you are building the gateway for a small amount of people, you will want to change the [[Wikipedia:Classless Inter-Domain Routing|CIDR]] suffix to accommodate a smaller range. For example {{ic|/27}} will give you {{ic|10.0.0.1}} to {{ic|10.0.0.30}}. You can find many CIDR calculators online.}}<br />
<br />
Next up is to set up the interfaces with netctl.<br />
# netctl enable extern0-profile<br />
# netctl enable intern0-profile<br />
<br />
==ADSL connection/PPPoE==<br />
Using rp-pppoe, we can connect an ADSL modem to the {{ic|extern0}} interface of the firewall and have Arch manage the connection. Make sure you put the modem in ''bridged'' mode though (either half-bridge or RFC1483), otherwise the modem will act as a router too. [[Install]] the {{pkg|rp-pppoe}} package.<br />
<br />
It should be noted that if you use only PPPoE to connect to the internet (ie. you do not have other WAN port, except for the one that connects to your modem) you do not need to set up the {{ic|extern0-profile}} as the external pseudo-interface will be ppp0.<br />
<br />
===PPPoE configuration===<br />
You can use netctl to setup the pppoe connection. To get started<br />
# cp /etc/netctl/examples/pppoe /etc/netctl/<br />
and start editing. For the interface configuration choose the interface that connects to the modem. If you only connect to the internet through PPPoE this will probably be {{ic|extern0}}. Fill in the rest of the fields with your ISP information. See the pppoe section in netctl.profile man page for more information on the fields.<br />
<br />
==DNS and DHCP==<br />
We will use [[dnsmasq]], a DNS and DHCP daemon for the LAN. It was specifically designed for small sites. [[Install]] it with the {{Pkg|dnsmasq}} package.<br />
<br />
Dnsmasq needs to be configured to be a DHCP server with a configuration similar to the following:<br />
{{hc|/etc/dnsmasq.conf|<nowiki><br />
interface=intern0 # make dnsmasq listen for requests only on intern0 (our LAN)<br />
expand-hosts # add a domain to simple hostnames in /etc/hosts<br />
domain=foo.bar # allow fully qualified domain names for DHCP hosts (needed when<br />
# "expand-hosts" is used)<br />
dhcp-range=10.0.0.2,10.0.0.255,255.255.255.0,1h # defines a DHCP-range for the LAN: <br />
# from 10.0.0.2 to .255 with a subnet mask of 255.255.255.0 and a<br />
# DHCP lease of 1 hour (change to your own preferences)<br />
</nowiki>}}<br />
<br />
Somewhere below, you will notice you can also add "static" DHCP leases, i.e. assign an IP-address to the MAC-address of a computer on the LAN. This way, whenever the computer requests a new lease, it will get the same IP. That is very useful for network servers with a DNS record. You can also deny certain MAC's from obtaining an IP.<br />
<br />
Now [[start]] and [[enable]] {{ic|dnsmasq.service}}.<br />
<br />
==Connection sharing==<br />
<br />
Time to tie the two network interfaces to each other.<br />
<br />
===Connection sharing with shorewall===<br />
<br />
See [[Shorewall]] for a detailed configuration guide.<br />
<br />
===Manual===<br />
<br />
First of all we need to allow packets to hop from one network interface to the other. See [[Internet sharing#Enable packet forwarding]] for details.<br />
<br />
In order for packets to be properly send and received it is necessary to translate the IP addresses between the outward facing network and the subnet used locally. The technique is called ''masquerading'' . We also need two forward rules to keep connections going and enable lan->wan forwarding. For this task we are going to use [[iptables]]:<br />
<br />
{{hc|/etc/iptables/iptables.rules|<br />
<nowiki>*nat<br />
:PREROUTING ACCEPT [0:0]<br />
:INPUT ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
:POSTROUTING ACCEPT [0:0]<br />
-A POSTROUTING -o extern0 -j MASQUERADE<br />
COMMIT<br />
<br />
<br />
*filter<br />
:INPUT ACCEPT [0:0]<br />
:FORWARD ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
-A FORWARD -i intern0 -o extern0 -j ACCEPT<br />
COMMIT<br />
<br />
</nowiki>}}<br />
<br />
If you're connecting via PPPoE you'll also need to clamp mss to pmtu in order the prevent fregmentation from happening:<br />
{{hc|/etc/iptables/iptables.rules|<br />
<nowiki><br />
*mangle<br />
:PREROUTING ACCEPT [0:0]<br />
:INPUT ACCEPT [0:0]<br />
:FORWARD ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
:POSTROUTING ACCEPT [0:0]<br />
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
COMMIT<br />
</nowiki>}}<br />
<br />
<br />
[[Start]] and [[enable]] {{ic|iptables.service}}. The router should now be fully functioning and route your traffic. However since it is facing the public internet it makes sense to additionally guard it using a [[Simple stateful firewall]].<br />
<br />
==IPv6 tips==<br />
<br />
{{Merge|IPv6|Merge into the main article, the topic is not specific to ''router configuration''. The wording should be probably changed along the way.}}<br />
<br />
Useful reading: [[IPv6]] and the [[wikipedia:IPv6]].<br />
<br />
=== Unique Local Addresses ===<br />
<br />
You can use your router in IPv6 mode even if you do not have an IPv6 address from your ISP. Unless you disable IPv6 all interfaces should have been assigned a unique {{ic|fe80::/10}} address.<br />
<br />
For internal networking the block {{ic|fc00::/7}} has been reserved. These addresses are guaranteed to be unique and non-routable from the open internet. Addresses that belong to the {{ic|fc00::/7}} block are called [[wikipedia:Unique_local_address|Unique Local Addresses]]. To get started [http://www.simpledns.com/private-ipv6.aspx generate a ULA /64 block] to use in your network. For this example we will use {{ic|fd00:aaaa:bbbb:cccc::/64}}. Firstly we must assign a static IPv6 on the internal interface. Modify the {{ic|intern0-profile}} we created above to include the following line<br />
<br />
IPCustom=('-6 addr add fd00:aaaa:bbbb:cccc::1/64 dev intern0')<br />
<br />
This will add the ULA to the internal interface. As far as the router goes, this is all you need to configure.<br />
<br />
=== Global Unicast Addresses ===<br />
<br />
If your ISP or WAN network can access the IPv6 Internet you can additionally assign global link addresses to your router and propagate them through SLAAC to your internal network. The global unicast prefix is usually either ''static'' or provided through ''prefix delegation''.<br />
<br />
==== Static IPv6 prefix ====<br />
<br />
If your ISP has provided you with a static prefix then edit {{ic|/etc/netctl/extern0-profile}} and simply add the IPv6 and the IPv6 prefix (usually /64) you have been provided<br />
<br />
IPCustom=('-6 addr add 2002:1:2:3:4:5:6:7/64 dev extern0')<br />
<br />
You can use this in addition to the ULA address described above.<br />
<br />
====Acquiring IPv6 prefix via DHCPv6-PD====<br />
<br />
If your ISP handles IPv6 via prefix delegation then you can follow the instructions in the [[IPv6#Prefix_delegation_.28DHCPv6-PD.29|main IPv6 article]] on how to properly configure your router. Following the conventions of this article the WAN interface is {{ic|extern0}} (or {{ic|ppp0}} if you are connecting through PPPoE) and the LAN interface is {{ic|intern0}}.<br />
<br />
=== Router Advertisement and Stateless Autoconfiguration (SLAAC) ===<br />
<br />
To properly hand out IPv6s to the network clients we will need to use an advertising daemon. Follow the details of the [[IPv6#For_gateways|main IPv6 article]] on how to setup {{ic|radvd}}. Following the convention of this guide the LAN facing interfaces is {{ic|intern0}}. You can either advertise all prefixes or choose which prefixes will be assigned to the local network.<br />
<br />
==Optional additions==<br />
<br />
===UPnP===<br />
The above configuration of shorewall does not include [[Wikipedia:UPnP|UPnP]] support. Use of UPnP is discouraged as it may make the gateway vulnerable to attacks from within the LAN. However, some applications require this to function correctly.<br />
<br />
To enable UPnP on your router, you need to install an UPnP Internet gateway daemon (IGD). To get it, [[install]] the {{Pkg|miniupnpd}} package.<br />
<br />
Read the [http://www.shorewall.net/UPnP.html Shorewall guide on UPnP] for more information<br />
<br />
===Remote administration===<br />
<br />
[[OpenSSH]] can be used to administer your router remotely. This is useful for running it "headless" (no monitor or input devices).<br />
<br />
=== Caching web proxy ===<br />
<br />
See [[Squid]] or [[Polipo]] for the setup of a web proxy to speed up browsing and/or adding an extra layer of security.<br />
<br />
=== Time server ===<br />
To use the router as a time server, see [[Network Time Protocol daemon]].<br />
<br />
Then, configure shorewall or iptables to allow NTP traffic in and out.<br />
<br />
=== Content filtering ===<br />
<br />
Install and configure [[DansGuardian]] or [[Privoxy]] if you need a content filtering solution.<br />
<br />
=== Traffic shaping ===<br />
<br />
Traffic shaping is very useful, especially when you are not the only one on the LAN. The idea is to assign a priority to different types of traffic. Interactive traffic (ssh, online gaming) probably needs the highest priority, while P2P traffic can do with the lowest. Then there is everything in between.<br />
<br />
==== Traffic shaping with shorewall ====<br />
See [[Shorewall#Traffic shaping]]<br />
<br />
==See also==<br />
*[[Simple stateful firewall]]<br />
*[[Internet sharing]]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Router&diff=517542Router2018-04-15T04:27:48Z<p>Phil.r.dubois: /* Persistent interface naming */ typo</p>
<hr />
<div>[[Category:Network sharing]]<br />
[[Category:Security]]<br />
[[Category:Firewalls]]<br />
[[ja:ルーター]]<br />
[[zh-hans:Router]]<br />
This article is a tutorial for turning a computer into an internet gateway/router. To strengthen its security it should not run '''any''' services available to the outside world. Towards the LAN, run only gateway specific services especially do not run httpd, ftpd, samba, nfsd, etc. as those belong on a server in the LAN since they introduce security risks.<br />
<br />
This article does not attempt to show how to set up a shared connection between 2 PCs using cross-over cables. For a simple internet sharing solution, see [[Internet sharing]].<br />
<br />
{{Note|Throughout the article '''intern0''' and '''extern0''' are used as names for the network interfaces. The reasoning is further explained in [[#Persistent interface naming]].}}<br />
<br />
==Hardware Requirements==<br />
* At least 1 GB of hard drive space. The base install will take up around 500MB of space and if you want to use a caching web proxy, you will need to reserve space for the cache as well.<br />
* At least two physical network interfaces: a gateway connects two networks with each other (actually router can be made using single physical interface that underlay two VLAN interfaces and connected to VLAN-aware switch, so-called router-on-a-stick configuration, but it is not covered in this article). You will need to be able to connect those networks to the same physical computer. One interface must connect to the external network, while the other connects to the internal network.<br />
* A hub, switch or UTP cable: You need a way to connect the other computers to the gateway<br />
<br />
==Network interface configuration==<br />
<br />
===Persistent interface naming===<br />
Systemd automatically chooses unique interface names for all your interfaces. These are persistent and will not change when you reboot. <br />
However you might want to rename your interfaces e.g. in order to highlight their different networks to which they connect. In the following sections of this guide the below stated convention is used throughout:<br />
<br />
* '''intern0''': the network card connected to the LAN. On an actual computer it will probably have the name enp2s0, enp1s1, etc.<br />
* '''extern0''': the network card connected to the external network (or WAN). It will probably have the name enp2s0, enp1s1, etc.<br />
<br />
You may change the assigned names of your devices via a configuration file using [[Systemd-networkd]] described in [[Systemd-networkd#Renaming an interface]] or by a [[udev]]-rule following [[Network configuration#Change device name]]. Due the example-rich nature of this article you might want to for example choose the above described names.<br />
<br />
===IP configuration===<br />
Now you will need to configure the network interfaces. The best way to do so is using [[netctl]] profiles. You will need to create two profiles.<br />
{{Note|If you will be connecting to the Internet only via PPPoE (you have one WAN port) you '''do not need''' to setup or enable the extern0-profile. See below for more information on configuring PPPoE.}}<br />
* {{ic|/etc/netctl/extern0-profile}}<br />
Description='Public Interface.'<br />
Interface=extern0<br />
Connection=ethernet<br />
IP='dhcp'<br />
<br />
* {{ic|/etc/netctl/intern0-profile}}<br />
Description='Private Interface'<br />
Interface=intern0<br />
Connection=ethernet<br />
IP='static'<br />
Address=('10.0.0.1/24')<br />
<br />
{{Note|The example configuration above assumes a full subnet. If you are building the gateway for a small amount of people, you will want to change the [[Wikipedia:Classless Inter-Domain Routing|CIDR]] suffix to accommodate a smaller range. For example {{ic|/27}} will give you {{ic|10.0.0.1}} to {{ic|10.0.0.30}}. You can find many CIDR calculators online.}}<br />
<br />
Next up is to set up the interfaces with netctl.<br />
# netctl enable extern0-profile<br />
# netctl enable intern0-profile<br />
<br />
==ADSL connection/PPPoE==<br />
Using rp-pppoe, we can connect an ADSL modem to the {{ic|extern0}} interface of the firewall and have Arch manage the connection. Make sure you put the modem in ''bridged'' mode though (either half-bridge or RFC1483), otherwise the modem will act as a router too. [[Install]] the {{pkg|rp-pppoe}} package.<br />
<br />
It should be noted that if you use only PPPoE to connect to the internet (ie. you do not have other WAN port, except for the one that connects to your modem) you do not need to set up the {{ic|extern0-profile}} as the external pseudo-interface will be ppp0.<br />
<br />
===PPPoE configuration===<br />
You can use netctl to setup the pppoe connection. To get started<br />
# cp /etc/netctl/examples/pppoe /etc/netctl/<br />
and start editing. For the interface configuration choose the interface that connects to the modem. If you only connect to the internet through PPPoE this will probably be {{ic|extern0}}. Fill in the rest of the fields with your ISP information. See the pppoe section in netctl.profile man page for more information on the fields.<br />
<br />
==DNS and DHCP==<br />
We will use [[dnsmasq]], a DNS and DHCP daemon for the LAN. It was specifically designed for small sites. [[Install]] it with the {{Pkg|dnsmasq}} package.<br />
<br />
Dnsmasq needs to be configured to be a DHCP server with a configuration similar to the following:<br />
{{hc|/etc/dnsmasq.conf|<nowiki><br />
interface=intern0 # make dnsmasq listen for requests only on intern0 (our LAN)<br />
expand-hosts # add a domain to simple hostnames in /etc/hosts<br />
domain=foo.bar # allow fully qualified domain names for DHCP hosts (needed when<br />
# "expand-hosts" is used)<br />
dhcp-range=10.0.0.2,10.0.0.255,255.255.255.0,1h # defines a DHCP-range for the LAN: <br />
# from 10.0.0.2 to .255 with a subnet mask of 255.255.255.0 and a<br />
# DHCP lease of 1 hour (change to your own preferences)<br />
</nowiki>}}<br />
<br />
Somewhere below, you will notice you can also add "static" DHCP leases, i.e. assign an IP-address to the MAC-address of a computer on the LAN. This way, whenever the computer requests a new lease, it will get the same IP. That is very useful for network servers with a DNS record. You can also deny certain MAC's from obtaining an IP.<br />
<br />
Now [[start]] and [[enable]] {{ic|dnsmasq.service}}.<br />
<br />
==Connection sharing==<br />
<br />
Time to tie the two network interfaces to each other.<br />
<br />
===Connection sharing with shorewall===<br />
<br />
See [[Shorewall]] for a detailed configuration guide.<br />
<br />
===Manual===<br />
<br />
First of all we need to allow packets to hop from one network interface to the other. See [[Internet sharing#Enable packet forwarding]] for details.<br />
<br />
In order for packets to be properly send and received it is necessary to translate the IP addresses between the outward facing network and the subnet used locally. The technique is called ''masquerading'' . We also need two forward rules to keep connections going and enable lan->wan forwarding. For this task we are going to use [[iptables]]:<br />
<br />
{{hc|/etc/iptables/iptables.rules|<br />
<nowiki>*nat<br />
:PREROUTING ACCEPT [0:0]<br />
:INPUT ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
:POSTROUTING ACCEPT [0:0]<br />
-A POSTROUTING -o extern0 -j MASQUERADE<br />
COMMIT<br />
<br />
<br />
*filter<br />
:INPUT ACCEPT [0:0]<br />
:FORWARD ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
-A FORWARD -i intern0 -o extern0 -j ACCEPT<br />
COMMIT<br />
<br />
</nowiki>}}<br />
<br />
If you're connecting via PPPoE you'll also need to clamp mss to pmtu in order the prevent fregmentation from happening:<br />
{{hc|/etc/iptables/iptables.rules|<br />
<nowiki><br />
*mangle<br />
:PREROUTING ACCEPT [0:0]<br />
:INPUT ACCEPT [0:0]<br />
:FORWARD ACCEPT [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
:POSTROUTING ACCEPT [0:0]<br />
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
COMMIT<br />
</nowiki>}}<br />
<br />
<br />
[[Start]] and [[enable]] {{ic|iptables.service}}. The router should now be fully functioning and route your traffic. However since it is facing the public internet it makes sense to additionally guard it using a [[Simple stateful firewall]].<br />
<br />
==IPv6 tips==<br />
<br />
{{Merge|IPv6|Merge into the main article, the topic is not specific to ''router configuration''. The wording should be probably changed along the way.}}<br />
<br />
Useful reading: [[IPv6]] and the [[wikipedia:IPv6]].<br />
<br />
=== Unique Local Addresses ===<br />
<br />
You can use your router in IPv6 mode even if you do not have an IPv6 address from your ISP. Unless you disable IPv6 all interfaces should have been assigned a unique {{ic|fe80::/10}} address.<br />
<br />
For internal networking the block {{ic|fc00::/7}} has been reserved. These addresses are guaranteed to be unique and non-routable from the open internet. Addresses that belong to the {{ic|fc00::/7}} block are called [[wikipedia:Unique_local_address|Unique Local Addresses]]. To get started [http://www.simpledns.com/private-ipv6.aspx generate a ULA /64 block] to use in your network. For this example we will use {{ic|fd00:aaaa:bbbb:cccc::/64}}. Firstly we must assign a static IPv6 on the internal interface. Modify the {{ic|intern0-profile}} we created above to include the following line<br />
<br />
IPCustom=('-6 addr add fd00:aaaa:bbbb:cccc::1/64 dev intern0')<br />
<br />
This will add the ULA to the internal interface. As far as the router goes, this is all you need to configure.<br />
<br />
=== Global Unicast Addresses ===<br />
<br />
If your ISP or WAN network can access the IPv6 Internet you can additionally assign global link addresses to your router and propagate them through SLAAC to your internal network. The global unicast prefix is usually either ''static'' or provided through ''prefix delegation''.<br />
<br />
==== Static IPv6 prefix ====<br />
<br />
If your ISP has provided you with a static prefix then edit {{ic|/etc/netctl/extern0-profile}} and simply add the IPv6 and the IPv6 prefix (usually /64) you have been provided<br />
<br />
IPCustom=('-6 addr add 2002:1:2:3:4:5:6:7/64 dev extern0')<br />
<br />
You can use this in addition to the ULA address described above.<br />
<br />
====Acquiring IPv6 prefix via DHCPv6-PD====<br />
<br />
If your ISP handles IPv6 via prefix delegation then you can follow the instructions in the [[IPv6#Prefix_delegation_.28DHCPv6-PD.29|main IPv6 article]] on how to properly configure your router. Following the conventions of this article the WAN interface is {{ic|extern0}} (or {{ic|ppp0}} if you are connecting through PPPoE) and the LAN interface is {{ic|intern0}}.<br />
<br />
=== Router Advertisement and Stateless Autoconfiguration (SLAAC) ===<br />
<br />
To properly hand out IPv6s to the network clients we will need to use an advertising daemon. Follow the details of the [[IPv6#For_gateways|main IPv6 article]] on how to setup {{ic|radvd}}. Following the convention of this guide the LAN facing interfaces is {{ic|intern0}}. You can either advertise all prefixes or choose which prefixes will be assigned to the local network.<br />
<br />
==Optional additions==<br />
<br />
===UPnP===<br />
The above configuration of shorewall does not include [[Wikipedia:UPnP|UPnP]] support. Use of UPnP is discouraged as it may make the gateway vulnerable to attacks from within the LAN. However, some applications require this to function correctly.<br />
<br />
To enable UPnP on your router, you need to install an UPnP Internet gateway daemon (IGD). To get it, [[install]] the {{Pkg|miniupnpd}} package.<br />
<br />
Read the [http://www.shorewall.net/UPnP.html Shorewall guide on UPnP] for more information<br />
<br />
===Remote administration===<br />
<br />
[[OpenSSH]] can be used to administer your router remotely. This is useful for running it "headless" (no monitor or input devices).<br />
<br />
=== Caching web proxy ===<br />
<br />
See [[Squid]] or [[Polipo]] for the setup of a web proxy to speed up browsing and/or adding an extra layer of security.<br />
<br />
=== Time server ===<br />
To use the router as a time server, see [[Network Time Protocol daemon]].<br />
<br />
Then, configure shorewall or iptables to allow NTP traffic in and out.<br />
<br />
=== Content filtering ===<br />
<br />
Install and configure [[DansGuardian]] or [[Privoxy]] if you need a content filtering solution.<br />
<br />
=== Traffic shaping ===<br />
<br />
Traffic shaping is very useful, especially when you are not the only one on the LAN. The idea is to assign a priority to different types of traffic. Interactive traffic (ssh, online gaming) probably needs the highest priority, while P2P traffic can do with the lowest. Then there is everything in between.<br />
<br />
==== Traffic shaping with shorewall ====<br />
See [[Shorewall#Traffic shaping]]<br />
<br />
==See also==<br />
*[[Simple stateful firewall]]<br />
*[[Internet sharing]]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Xpra&diff=516443Xpra2018-04-07T21:07:18Z<p>Phil.r.dubois: /* as xorg sandbox */ grammar</p>
<hr />
<div>[[Category:X server]]<br />
[[Category:Remote desktop]]<br />
[[ja:Xpra]]<br />
From the [http://xpra.org/ Xpra website]:<br />
<br />
Xpra is '[[screen]] for X': it allows you to run X programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state. It gives you remote access to individual applications. <br />
<br />
* Xpra is "rootless" or "seamless": programs you run under it show up on your desktop as regular programs, managed by your regular window manager.<br />
* Sessions can be accessed over SSH, or password protected over plain TCP sockets. <br />
* Xpra is usable over reasonably slow links and does its best to adapt to changing network bandwidth limits. (see also adaptive JPEG mode) <br />
* Xpra is open-source (GPLv2+), multi-platform and multi-language, with current clients written in Python and Java.<br />
<br />
==Installation==<br />
[[Install]] the package {{AUR|xpra}} from the [[AUR]], on the server and the clients.<br />
<br />
{{Tip|1=If you intend to run Xpra locally under a existing Xorg session with graphic drivers such as {{ic|<nowiki>nvidia</nowiki>}} or {{ic|<nowiki>ATi</nowiki>}} you will need to modify the default xpra config. Xpra fetches {{ic|-configdir}} from {{ic|xorg-server-xvfb}} which will be {{ic|/etc/X11/xorg.conf.d}}, therefore you need to change this by following the three bottom steps of [https://bbs.archlinux.org/viewtopic.php?pid=1333056#p1333056 1333056#p1333056] in order to run xpra locally.}}<br />
<br />
==Use==<br />
===run applications===<br />
Start an xpra server on the machine where you want to run the applications (we are using display number '''7''' here):<br />
<br />
{{bc|$ xpra start :7}}<br />
<br />
Now you can start an application, e.g. firefox:<br />
{{bc|1=$ DISPLAY=:7 firefox}}<br />
<br />
Or, if you want to start a screen session and execute the programs from there to be able to close the console:<br />
{{bc|1=<br />
$ DISPLAY=:7 screen<br />
[screen starts]<br />
$ firefox<br />
}}<br />
Note that if you start {{ic|screen}} like this you don't have to specify the display number when executing programs. They will be running on the xpra display automatically.<br />
<br />
After running these commands, you don't see any windows yet. To actually see the applications on your display, you have to connect to the xpra server. If you are connecting to an xpra display on the same machine, start the xpra client like this:<br />
{{bc|$ xpra attach :7}}<br />
<br />
Or, if you are connecting to a remote machine over ssh:<br />
{{bc|$ xpra attach ssh:user@example.com:7}}<br />
<br />
After starting the client, any programs running on the remote server display are displayed on your local screen. To detach, type {{ic|ctrl-c}} or use the command:<br />
{{bc|$ xpra detach ssh:user@example.com:7}}<br />
Programs continue to run on the server and you can reattach again later.<br />
<br />
You can stop the server with:<br />
{{bc|$ xpra stop :7}}<br />
on the machine where the server is running, or remotely:<br />
{{bc|$ xpra stop ssh:user@example.com:7}}<br />
<br />
===run whole desktop environment===<br />
To run whole desktop (on the server side):<br />
{{bc|$ <nowiki>xpra start-desktop :7 --start-child=xfce4-session --exit-with-children</nowiki>}}<br />
<br />
where:<br />
* {{ic|:7}} is a number of xorg DISPLAY session<br />
* {{ic|<nowiki>--start-child=xfce4-session</nowiki>}} run xfce4 session as child on xpra server<br />
* {{ic|--exit-with-children}} mean that server will be closed after session logout (children exit)<br />
<br />
To attach it (on the server side):<br />
<br />
{{bc|$ xpra attach :7}}<br />
<br />
To attach it (on the client side):<br />
<br />
{{bc|$ xpra attach ssh:user@example.com:7}}<br />
<br />
To detach press ctrl+c on terminal or run:<br />
<br />
{{bc|$ xpra detach :7}}<br />
<br />
{{Tip|1=Screen resolution can be changed with [[xrandr]].}}<br />
<br />
===shadow remote desktop===<br />
To clone:<br />
* display must be auth by this same user as ssh login to<br />
* display must be shown on remote screen<br />
<br />
To shadow desktop run this on the client side:<br />
<br />
{{bc|$ xpra shadow ssh:DISPLAY_user@example.com:DISPLAY_number}}<br />
<br />
===as xorg sandbox===<br />
Sandox can be achieved with [[firejail]]:<br />
* for application sandbox (change {{ic|eth0}} to your interface name or to {{ic|none}}):<br />
{{bc|$ <nowiki>firejail --x11=xpra --net=eth0 firefox</nowiki>}}<br />
* xpra attach, etc:<br />
{{bc|$ <nowiki>firejail --net=eth0 xpra [...]</nowiki>}}<br />
<br />
{{Note|1={{ic|<nowiki>--net=eth0</nowiki>}} creates a separate namespace for the network. This is necessary to hide all xorg or system sockets from xpra, otherwise a sandbox is most likely ineffective ([https://github.com/netblue30/firejail/issues/57#issuecomment-153757284 issue-54#153757284]).}}<br />
<br />
===more===<br />
For a complete manual, check {{ic|man xpra}}.<br />
<br />
==Tips and tricks==<br />
=== Start at boot ===<br />
==== Server ====<br />
It is possible to start the xpra server at boot using a [[systemd]] unit.<br />
<br />
Create the unit file:<br />
{{hc|/etc/systemd/system/xpra@.service|<nowiki><br />
[Unit]<br />
Description=xpra display<br />
<br />
[Service]<br />
Type=simple<br />
User=%i<br />
EnvironmentFile=/etc/conf.d/xpra<br />
ExecStart=/usr/bin/xpra --no-daemon start ${%i}<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Now create the configuration, adding a line for each username you want to have an xpra display:<br />
{{hc|/etc/conf.d/xpra|<nowiki><br />
myusername=:7<br />
</nowiki>}}<br />
[[Daemons|Enable the service]] for each username that owns a display. In this example, the service would be {{ic|xpra@myusername.service}}.<br />
==== Client ====<br />
{{Note|If the client is a remote machine, first of all use SSH keys to be able to connect to the server without typing a password. Read [[SSH keys]] for more details.}}<br />
<br />
===== Method 1: .xinitrc =====<br />
Add to your {{ic|~/.xinitrc}} file the line necessary to start the connection, adding an '''&''' at the end of the line.<br />
<br />
Make sure to add such line '''before''' the {{ic|exec}} line.<br />
<br />
For example, on a remote client it could be:<br />
{{hc|~/.xinitrc|<br />
xpra attach ssh:user@example.com:7 &<br />
}}<br />
===== Method 2: systemd user session =====<br />
Configure your session to use '''systemd user session'''. Read [[Systemd/User]] for details.<br />
{{Note|Make sure you understand the difference between '''systemd user session''' services, and regular '''systemd''' services. Again, read the [[Systemd/User]] for details.}}<br />
<br />
Create the following service unit:<br />
{{hc|$HOME/.config/systemd/user/xpra-client@.service|<nowiki><br />
[Unit]<br />
Description=xpra client<br />
<br />
[Service]<br />
Type=simple<br />
EnvironmentFile=%h/.config/conf/xpra_client<br />
ExecStart=/usr/bin/xpra attach %i $OPTS<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
Create the configuration file, using the options you want:<br />
{{hc|$HOME/.config/conf/xpra_client|<nowiki><br />
OPTS=--encoding=jpeg --quality=90<br />
</nowiki>}}<br />
The service name would be in the format of {{ic|xpra-client@''ssh:username@hostname''':<display number>'''''.service}}.<br />
<br />
Example:<br />
{{bc|xpra-client@ssh:myuser@example.com:7.service}}<br />
[[Daemons|Enable that service]], and remember to use the {{ic|--user}} flag on {{ic|systemctl}}.<br />
<br />
===Error: Only console users are allowed to run the X server===<br />
<br />
If the execution fails with this error message in the log file you need to make the following changes:<br />
<br />
Create the file /etc/X11/Xwrapper.config with the content <br />
<br />
{{hc|/etc/X11/Xwrapper.config|<nowiki><br />
allowed_users=anybody<br />
</nowiki>}}<br />
<br />
==See also==<br />
* [http://xpra.org/ Xpra website]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Xpra&diff=516442Xpra2018-04-07T20:49:50Z<p>Phil.r.dubois: /* Installation */ grammar</p>
<hr />
<div>[[Category:X server]]<br />
[[Category:Remote desktop]]<br />
[[ja:Xpra]]<br />
From the [http://xpra.org/ Xpra website]:<br />
<br />
Xpra is '[[screen]] for X': it allows you to run X programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state. It gives you remote access to individual applications. <br />
<br />
* Xpra is "rootless" or "seamless": programs you run under it show up on your desktop as regular programs, managed by your regular window manager.<br />
* Sessions can be accessed over SSH, or password protected over plain TCP sockets. <br />
* Xpra is usable over reasonably slow links and does its best to adapt to changing network bandwidth limits. (see also adaptive JPEG mode) <br />
* Xpra is open-source (GPLv2+), multi-platform and multi-language, with current clients written in Python and Java.<br />
<br />
==Installation==<br />
[[Install]] the package {{AUR|xpra}} from the [[AUR]], on the server and the clients.<br />
<br />
{{Tip|1=If you intend to run Xpra locally under a existing Xorg session with graphic drivers such as {{ic|<nowiki>nvidia</nowiki>}} or {{ic|<nowiki>ATi</nowiki>}} you will need to modify the default xpra config. Xpra fetches {{ic|-configdir}} from {{ic|xorg-server-xvfb}} which will be {{ic|/etc/X11/xorg.conf.d}}, therefore you need to change this by following the three bottom steps of [https://bbs.archlinux.org/viewtopic.php?pid=1333056#p1333056 1333056#p1333056] in order to run xpra locally.}}<br />
<br />
==Use==<br />
===run applications===<br />
Start an xpra server on the machine where you want to run the applications (we are using display number '''7''' here):<br />
<br />
{{bc|$ xpra start :7}}<br />
<br />
Now you can start an application, e.g. firefox:<br />
{{bc|1=$ DISPLAY=:7 firefox}}<br />
<br />
Or, if you want to start a screen session and execute the programs from there to be able to close the console:<br />
{{bc|1=<br />
$ DISPLAY=:7 screen<br />
[screen starts]<br />
$ firefox<br />
}}<br />
Note that if you start {{ic|screen}} like this you don't have to specify the display number when executing programs. They will be running on the xpra display automatically.<br />
<br />
After running these commands, you don't see any windows yet. To actually see the applications on your display, you have to connect to the xpra server. If you are connecting to an xpra display on the same machine, start the xpra client like this:<br />
{{bc|$ xpra attach :7}}<br />
<br />
Or, if you are connecting to a remote machine over ssh:<br />
{{bc|$ xpra attach ssh:user@example.com:7}}<br />
<br />
After starting the client, any programs running on the remote server display are displayed on your local screen. To detach, type {{ic|ctrl-c}} or use the command:<br />
{{bc|$ xpra detach ssh:user@example.com:7}}<br />
Programs continue to run on the server and you can reattach again later.<br />
<br />
You can stop the server with:<br />
{{bc|$ xpra stop :7}}<br />
on the machine where the server is running, or remotely:<br />
{{bc|$ xpra stop ssh:user@example.com:7}}<br />
<br />
===run whole desktop environment===<br />
To run whole desktop (on the server side):<br />
{{bc|$ <nowiki>xpra start-desktop :7 --start-child=xfce4-session --exit-with-children</nowiki>}}<br />
<br />
where:<br />
* {{ic|:7}} is a number of xorg DISPLAY session<br />
* {{ic|<nowiki>--start-child=xfce4-session</nowiki>}} run xfce4 session as child on xpra server<br />
* {{ic|--exit-with-children}} mean that server will be closed after session logout (children exit)<br />
<br />
To attach it (on the server side):<br />
<br />
{{bc|$ xpra attach :7}}<br />
<br />
To attach it (on the client side):<br />
<br />
{{bc|$ xpra attach ssh:user@example.com:7}}<br />
<br />
To detach press ctrl+c on terminal or run:<br />
<br />
{{bc|$ xpra detach :7}}<br />
<br />
{{Tip|1=Screen resolution can be changed with [[xrandr]].}}<br />
<br />
===shadow remote desktop===<br />
To clone:<br />
* display must be auth by this same user as ssh login to<br />
* display must be shown on remote screen<br />
<br />
To shadow desktop run this on the client side:<br />
<br />
{{bc|$ xpra shadow ssh:DISPLAY_user@example.com:DISPLAY_number}}<br />
<br />
===as xorg sandbox===<br />
Sandox can be achieved with [[firejail]]:<br />
* for application sandbox (change {{ic|eth0}} to your interface name or to {{ic|none}}):<br />
{{bc|$ <nowiki>firejail --x11=xpra --net=eth0 firefox</nowiki>}}<br />
* xpra attach, etc:<br />
{{bc|$ <nowiki>firejail --net=eth0 xpra [...]</nowiki>}}<br />
<br />
{{Note|1={{ic|<nowiki>--net=eth0</nowiki>}} create separate namespace for network, this is necessary to hide all xorg or system sockets from xpra, otherwise sanbox is most likely ineffective ([https://github.com/netblue30/firejail/issues/57#issuecomment-153757284 issue-54#153757284]).}}<br />
<br />
===more===<br />
For a complete manual, check {{ic|man xpra}}.<br />
<br />
==Tips and tricks==<br />
=== Start at boot ===<br />
==== Server ====<br />
It is possible to start the xpra server at boot using a [[systemd]] unit.<br />
<br />
Create the unit file:<br />
{{hc|/etc/systemd/system/xpra@.service|<nowiki><br />
[Unit]<br />
Description=xpra display<br />
<br />
[Service]<br />
Type=simple<br />
User=%i<br />
EnvironmentFile=/etc/conf.d/xpra<br />
ExecStart=/usr/bin/xpra --no-daemon start ${%i}<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Now create the configuration, adding a line for each username you want to have an xpra display:<br />
{{hc|/etc/conf.d/xpra|<nowiki><br />
myusername=:7<br />
</nowiki>}}<br />
[[Daemons|Enable the service]] for each username that owns a display. In this example, the service would be {{ic|xpra@myusername.service}}.<br />
==== Client ====<br />
{{Note|If the client is a remote machine, first of all use SSH keys to be able to connect to the server without typing a password. Read [[SSH keys]] for more details.}}<br />
<br />
===== Method 1: .xinitrc =====<br />
Add to your {{ic|~/.xinitrc}} file the line necessary to start the connection, adding an '''&''' at the end of the line.<br />
<br />
Make sure to add such line '''before''' the {{ic|exec}} line.<br />
<br />
For example, on a remote client it could be:<br />
{{hc|~/.xinitrc|<br />
xpra attach ssh:user@example.com:7 &<br />
}}<br />
===== Method 2: systemd user session =====<br />
Configure your session to use '''systemd user session'''. Read [[Systemd/User]] for details.<br />
{{Note|Make sure you understand the difference between '''systemd user session''' services, and regular '''systemd''' services. Again, read the [[Systemd/User]] for details.}}<br />
<br />
Create the following service unit:<br />
{{hc|$HOME/.config/systemd/user/xpra-client@.service|<nowiki><br />
[Unit]<br />
Description=xpra client<br />
<br />
[Service]<br />
Type=simple<br />
EnvironmentFile=%h/.config/conf/xpra_client<br />
ExecStart=/usr/bin/xpra attach %i $OPTS<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
Create the configuration file, using the options you want:<br />
{{hc|$HOME/.config/conf/xpra_client|<nowiki><br />
OPTS=--encoding=jpeg --quality=90<br />
</nowiki>}}<br />
The service name would be in the format of {{ic|xpra-client@''ssh:username@hostname''':<display number>'''''.service}}.<br />
<br />
Example:<br />
{{bc|xpra-client@ssh:myuser@example.com:7.service}}<br />
[[Daemons|Enable that service]], and remember to use the {{ic|--user}} flag on {{ic|systemctl}}.<br />
<br />
===Error: Only console users are allowed to run the X server===<br />
<br />
If the execution fails with this error message in the log file you need to make the following changes:<br />
<br />
Create the file /etc/X11/Xwrapper.config with the content <br />
<br />
{{hc|/etc/X11/Xwrapper.config|<nowiki><br />
allowed_users=anybody<br />
</nowiki>}}<br />
<br />
==See also==<br />
* [http://xpra.org/ Xpra website]</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=Python&diff=515657Python2018-04-03T04:35:52Z<p>Phil.r.dubois: /* Python 3 */ grammar</p>
<hr />
<div>[[Category:Programming languages]]<br />
[[de:Python]]<br />
[[es:Python]]<br />
[[ja:Python]]<br />
[[ko:Python]]<br />
[[ru:Python]]<br />
[[zh-hans:Python]]<br />
{{Related articles start}}<br />
{{Related|Python package guidelines}}<br />
{{Related|Python/Virtual environment}}<br />
{{Related|mod_wsgi}}<br />
{{Related|Django}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Python (programming language)|Wikipedia]]:<br />
<br />
:Python is a widely used high-level, general-purpose, interpreted, dynamic programming language. Its design philosophy emphasizes code readability, and its syntax allows programmers to express concepts in fewer lines of code than possible in languages such as C++ or Java. The language provides constructs intended to enable writing clear programs on both a small and large scale.<br />
:Python supports multiple programming paradigms, including object-oriented, imperative and functional programming or procedural styles. It features a dynamic type system and automatic memory management and has a large and comprehensive standard library.<br />
<br />
== Installation ==<br />
<br />
=== Python 3 ===<br />
<br />
Python 3 is the latest version of the language, and is incompatible with Python 2. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places. For an overview of the differences, visit [https://wiki.python.org/moin/Python2orPython3 Python2orPython3] and the relevant [http://getpython3.com/diveintopython3/porting-code-to-python-3-with-2to3.html chapter] in Dive into Python 3.<br />
<br />
To install the latest version of Python 3, [[install]] the {{Pkg|python}} package.<br />
<br />
If you would like to build the latest RC/betas from source, visit [https://www.python.org/downloads/ Python Downloads]. The [[Arch User Repository]] also contains good [[PKGBUILD]]s. If you do decide to build the RC, note that the binary (by default) installs to {{ic|/usr/local/bin/python3.x}}.<br />
<br />
=== Python 2 ===<br />
<br />
To get the latest version of Python 2, [[install]] the {{Pkg|python2}} package.<br />
<br />
Python 2 will happily run alongside Python 3. You need to specify {{ic|python2}} in order to run this version.<br />
<br />
Any program requiring Python 2 needs to point to {{ic|/usr/bin/python2}}, instead of {{ic|/usr/bin/python}}, which points to Python 3. To do so, open the program or script in a [[List of applications/Documents#Text editors|text editor]] and change the first line. The line will show one of the following:<br />
<br />
#!/usr/bin/env python<br />
<br />
or<br />
<br />
#!/usr/bin/python<br />
<br />
In both cases, just change {{ic|python}} to {{ic|python2}} and the program will then use Python 2 instead of Python 3.<br />
<br />
Another way to force the use of python2 without altering the scripts is to call it explicitly with {{ic|python2}}:<br />
<br />
$ python2 ''myScript.py''<br />
<br />
Finally, you may not be able to control the script calls, but there is a way to trick the environment. It only works if the scripts use {{ic|#!/usr/bin/env python}}. It will not work with {{ic|#!/usr/bin/python}}. This trick relies on {{ic|env}} searching for the first corresponding entry in the {{ic|PATH}} variable.<br />
<br />
First create a dummy folder:<br />
<br />
$ mkdir ~/bin<br />
<br />
Then add a symlink {{ic|python}} to ''python2'' and the config scripts in it:<br />
<br />
$ ln -s /usr/bin/python2 ~/bin/python<br />
$ ln -s /usr/bin/python2-config ~/bin/python-config<br />
<br />
Finally put the new folder ''at the beginning'' of your {{ic|PATH}} variable:<br />
<br />
$ export PATH=~/bin:$PATH<br />
<br />
{{Note|This method of changing [[environment variables]] is not permanent and is only active in the current terminal session.}}<br />
<br />
To check which python interpreter is being used by {{ic|env}}, use the following command:<br />
<br />
$ which python<br />
<br />
A similar approach in tricking the environment, which also relies on {{ic|#!/usr/bin/env python}} to be called by the script in question, is to use a [[#Virtual environment|virtual environment]].<br />
<br />
=== Old versions ===<br />
<br />
{{warning|Python versions before 2.7 and 3.4 have not received any updates&mdash;including security patches&mdash;since at least 2014. Using older versions for Internet-facing applications or untrusted code may be dangerous and is not recommended.}}<br />
<br />
Old versions of Python are available via the [[AUR]] and may be useful for historical curiosity, old applications that do not run on current versions, or for testing Python programs intended to run on a distribution that comes with an older version:<br />
<br />
* Python 3.5: {{AUR|python35}}<br />
* Python 3.4: {{AUR|python34}}<br />
* Python 2.6: {{AUR|python26}}<br />
* Python 2.5: {{AUR|python25}}<br />
* Python 1.5: {{AUR|python15}}<br />
<br />
Extra modules/libraries for old versions of Python may be found on the AUR by searching for {{ic|python<''version without period''>}}, e.g. searching for "python26" for 2.6 modules.<br />
<br />
== Package management ==<br />
<br />
Although a great number of Python packages are readily available in the [[official repositories]] and the [[AUR]], the Python ecosystem provides its own package managers for use with [https://pypi.python.org/ PyPI], the Python Package Index:<br />
<br />
* {{App|pip|The PyPA tool for installing Python packages.|https://pip.pypa.io/|{{Pkg|python-pip}}, {{Pkg|python2-pip}}}}<br />
* {{App|setuptools|Easily download, build, install, upgrade, and uninstall Python packages.|https://setuptools.readthedocs.io/|{{Pkg|python-setuptools}}, {{Pkg|python2-setuptools}}}}<br />
<br />
For a brief history and feature comparison between the two, see [https://packaging.python.org/pip_easy_install/#pip-vs-easy-install pip vs easy_install]. Authoritative best practices in Python package management are detailed [https://packaging.python.org/ here].<br />
<br />
If you must use ''pip'', use a [[#Virtual environment|virtual environment]] or with {{ic|pip install --user}} to avoid conflicting with packages in {{ic|/usr}}. It is always preferred to [[System maintenance#Use the package manager to install software|use pacman to install software]].<br />
<br />
{{Note|There are also tools integrating ''pip'' with ''pacman'' by automatically generating PKGBUILDs for specified pip-packages: see [[Creating packages#PKGBUILD generators]].}}<br />
<br />
== Widget bindings ==<br />
<br />
The following [[Wikipedia:Widget toolkit|widget toolkit]] bindings are available:<br />
<br />
* {{App|TkInter|Tk bindings|https://wiki.python.org/moin/TkInter|standard module}}<br />
* {{App|pyQt|[[Qt]] bindings|https://riverbankcomputing.com/software/pyqt/intro|{{Pkg|python2-pyqt4}} {{Pkg|python2-pyqt5}} {{Pkg|python-pyqt4}} {{Pkg|python-pyqt5}}}}<br />
* {{App|pySide|[[Qt]] bindings|https://wiki.qt.io/PySide|{{Pkg|python2-pyside}} {{Pkg|python-pyside}}}}<br />
* {{App|pyGTK|[[GTK+|GTK+ 2]] bindings|http://www.pygtk.org/|{{Pkg|pygtk}}}}<br />
* {{App|PyGObject|[[GTK+|GTK+ 2/3]] bindings via GObject Introspection|https://wiki.gnome.org/PyGObject/|{{Pkg|python2-gobject2}} {{Pkg|python2-gobject}} {{Pkg|python-gobject2}} {{Pkg|python-gobject}}}}<br />
* {{App|wxPython|wxWidgets bindings|https://wxpython.org/|{{Pkg|wxpython}}}}<br />
<br />
To use these with Python, you may need to install the associated widget kits.<br />
<br />
== Tips and tricks ==<br />
<br />
=== IPython ===<br />
[http://ipython.org/ IPython] is an enhanced Python command line available in the official repositories as {{Pkg|ipython}} and {{Pkg|ipython2}}. If you want the IPython notebook, install {{Pkg|jupyter-notebook}} for the IPython3 notebook and {{Pkg|ipython2-notebook}} for the IPython2 notebook. Run:<br />
<br />
$ jupyter notebook<br />
<br />
to autostart the browser and run the IPython kernel. You can select the ''python'' version when creating the notebook in the browser.<br />
<br />
[https://bpython-interpreter.org/ bpython] is a ncurses interface to the Python interpreter, available in the official repositories as {{Pkg|bpython}} and {{Pkg|bpython2}}.<br />
<br />
=== Virtual environment ===<br />
<br />
Python provides tools to create isolated environments in which you can install packages without interfering with the other virtual environments nor with the system Python's packages. It could change the ''python'' interpreter used for a specific application. <br />
<br />
See [[Python/Virtual environment]] for details.<br />
<br />
=== Tab completion in Python2 shell ===<br />
<br />
Since Python 3.4 [https://docs.python.org/3/tutorial/interactive.html tab completion] is enabled by default, for Python 2 you can manually enable it by adding the following lines to a file referenced by the {{ic|PYTHONSTARTUP}} environment variable: [https://algorithmicallyrandom.blogspot.co.at/2009/09/tab-completion-in-python-shell-how-to.html]<br />
<br />
import rlcompleter<br />
import readline<br />
readline.parse_and_bind("tab: complete")<br />
<br />
== Troubleshooting ==<br />
=== Dealing with version problem in build scripts ===<br />
<br />
Many projects' build scripts assume {{ic|python}} to be Python 2, and that would eventually result in an error — typically complaining that {{ic|print 'foo'}} is invalid syntax. Luckily, many of them call ''python'' from the {{ic|PATH}} environment variable instead of hardcoding {{ic|#!/usr/bin/python}} in the shebang line, and the Python scripts are all contained within the project tree. So, instead of modifying the build scripts manually, there is a workaround. Create {{ic|/usr/local/bin/python}} with content like this:<br />
<br />
{{hc|/usr/local/bin/python|<nowiki><br />
#!/bin/bash<br />
script=$(readlink -f -- "$1")<br />
case "$script" in (/path/to/project1/*|/path/to/project2/*|/path/to/project3*)<br />
exec python2 "$@"<br />
;;<br />
esac<br />
<br />
exec python3 "$@"<br />
</nowiki>}}<br />
<br />
Where {{ic|<nowiki>/path/to/project1/*|/path/to/project2/*|/path/to/project3*</nowiki>}} is a list of patterns separated by {{ic|<nowiki>|</nowiki>}} matching all project trees. For some scripts, the path may not be the first parameter, for example Google SDK it sends "-S" as the first parameter. The readlink command should change to {{ic|1=script=$(readlink -f -- "$1")}}.<br />
<br />
Do not forget to make it [[executable]]. Afterwards scripts within the specified project trees will be run with Python 2.<br />
<br />
== See also ==<br />
<br />
* [http://shop.oreilly.com/product/0636920028154.do O'Reilly's Learning Python, 5th edition] commercial<br />
* [http://www.diveintopython.net/ Dive Into Python], [http://getpython3.com/diveintopython3/ Dive Into Python3]<br />
* [https://python.swaroopch.com/ A Byte of Python]<br />
* [https://learnpythonthehardway.org/ Learn Python the Hard Way]<br />
* [https://learnpython.org/ Learn Python]<br />
* [https://stephensugden.com/crash_into_python/ Crash into Python] (assumes familiarity with other programming languages)<br />
* [https://www.apress.com/book/9781590598726 Beginning Game Development with Python and Pygame] commercial<br />
* [http://www.greenteapress.com/thinkpython/ Think Python]<br />
* [https://pythonspot.com Pythonspot]<br />
* [http://www.techbeamers.com/python-tutorial-step-by-step/ Learn Python Step by Step]<br />
* [https://github.com/vinta/awesome-python awesome-python] - A curated list of Python frameworks, libraries, software and resources.<br />
* [https://github.com/mahmoud/boltons boltons] - Constructs/recipes/snippets that would be handy in the standard library.</div>Phil.r.duboishttps://wiki.archlinux.org/index.php?title=TigerVNC&diff=491182TigerVNC2017-09-24T11:09:54Z<p>Phil.r.dubois: /* Installation */ Grammar</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Remote desktop]]<br />
[[de:VNC]]<br />
[[es:TigerVNC]]<br />
[[ja:TigerVNC]]<br />
[[ru:Vncserver]]<br />
[[zh-hans:Virtual Network Computing]]<br />
{{Related articles start}}<br />
{{Related|x11vnc}}<br />
{{Related articles end}}<br />
[http://tigervnc.org/ TigerVNC] is an implementation of the [[Wikipedia:VNC|VNC]] protocol. This article focuses on the server functionality.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|tigervnc}} package. <br />
{{Note|This packages provides the requisite vncserver, x0vncserver and also vncviewer.}}<br />
<br />
Vncserver provides two major remote control abilities:<br />
# Virtual (headless) server is similar to the standard X server, but has a virtual screen rather than a physical one. The virtual server runs completely ''parallel'' to the physical X server should one be running.<br />
# Direct control of the local X session(s) which do run on the physical monitor.<br />
<br />
== Running vncserver for virtual (headless) sessions ==<br />
<br />
=== Create environment, config, and password files ===<br />
Vncserver will create its initial environment, config, and user password file the first time it is run. These will be stored in {{ic|~/.vnc}} which will be created if not present.<br />
<br />
{{hc|$ vncserver|<br />
You will require a password to access your desktops.<br />
<br />
Password:<br />
Verify:<br />
<br />
New 'mars:1 (facade)' desktop is mars:1<br />
<br />
Creating default startup script /home/facade/.vnc/xstartup<br />
Starting applications specified in /home/facade/.vnc/xstartup<br />
Log file is /home/facade/.vnc/mars:1.log<br />
}}<br />
<br />
Notice the :1 trailing the hostname. This is indicating the TCP port number on which the virtual vncserver is running. In this case, :1 is actually TCP port 5901 (5900+1). Running {{ic|vncserver}} a second time will create a second instance running on the next highest, free port, i.e 5902 (5900+2) which shall end in :2 as above.<br />
<br />
{{Note|Linux systems can have as many VNC servers as physical memory allows, all of which running in parallel to each other.}}<br />
<br />
Shutdown the vncserver by using the -kill switch:<br />
$ vncserver -kill :1<br />
<br />
==== Edit the environment file ====<br />
<br />
Vncserver sources {{ic|~/.vnc/xstartup}} which functions like an [[.xinitrc]] file. At a minimum, users should start a DE from this file. For more, see: [[General recommendations#Desktop environments]].<br />
<br />
For example, starting lxqt:<br />
<br />
{{hc|~/.vnc/xstartup|<br />
<nowiki>#!/bin/sh<br />
exec startlxqt<br />
</nowiki>}}<br />
<br />
==== Edit the optional config file ====<br />
<br />
With the release of tigervnc 1.60-1, support for parsing options in {{ic|~/.vnc/config}} has been implemented which obviates the need to call {{ic|vncserver}} with command line switches. The format is one option per line. An example is provided:<br />
{{hc|~/.vnc/config|<br />
<nowiki><br />
## Supported server options to pass to vncserver upon invocation can be listed<br />
## in this file. See the following manpages for more: vncserver(1) Xvnc(1).<br />
## Several common ones are shown below. Uncomment and modify to your liking.<br />
##<br />
securitytypes=tlsvnc<br />
desktop=sandbox<br />
geometry=1200x700<br />
dpi=96<br />
localhost<br />
alwaysshared<br />
</nowiki>}}<br />
<br />
=== Starting and stopping vncserver via systemd ===<br />
Systemd can manage the vncserver via a service in one of two modes using either a user or system service. Both are presented below.<br />
<br />
==== User mode ====<br />
{{Note|In order to keep the vncserver alive when the user logs out (physically or via ssh), one must enable the linger option for loginctl like this: {{ic|# loginctl enable-linger username}} Failure to do so will result in the vncserver getting killed when the user logs off the machine.}}<br />
<br />
Start the service in usermode:<br />
$ systemctl --user start vncserver@:1<br />
<br />
Enable the service in usermode:<br />
$ systemctl --user enable vncserver@:1<br />
<br />
==== System mode ====<br />
<br />
{{Warning|Do not run this service if your local area network is untrusted.}}<br />
<br />
Create {{ic|/etc/systemd/system/vncserver@'':1''.service}}, where {{ic|:1}} is the {{ic|$DISPLAY}} [[environment variable]]. <br />
<br />
Modify the service by defining the user ({{ic|1=User=}}) to run the server, and the desired [[Vncserver]] options ({{ic|1=usr/bin/vncserver %i -arg1 -arg2 -argn}}).<br />
<br />
{{hc|/etc/systemd/system/vncserver@'':1''.service|<nowiki><br />
[Unit]<br />
Description=Remote desktop service (VNC)<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=simple<br />
User=foo<br />
PAMName=login<br />
PIDFile=/home/foo/.vnc/%H%i.pid<br />
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'<br />
ExecStart=/usr/bin/vncserver %i -geometry 1440x900 -alwaysshared -fg<br />
ExecStop=/usr/bin/vncserver -kill %i<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
[[Start]] {{ic|vncserver@'':1''.service}} and optionally [[enable]] it to run at boot time/shutdown.<br />
<br />
==== Multi-user mode ====<br />
One can use systemd socket activation in combination with [[XDMCP]] to automatically spawn VNC servers for each user who attempts to login, so there is no need to set up one server/port per user. This setup uses the display manager to authenticate users and login, so there is no need for VNC passwords. The downside is that users cannot leave a session running on the server and reconnect to it later.<br />
To get this running, first set up [[XDMCP]] and make sure the display manager is running.<br />
Then create:<br />
{{hc|/etc/systemd/system/xvnc.socket|<br />
<nowiki><br />
[Unit]<br />
Description=XVNC Server<br />
<br />
[Socket]<br />
ListenStream=5900<br />
Accept=yes<br />
<br />
[Install]<br />
WantedBy=sockets.target<br />
</nowiki>}}<br />
{{hc|/etc/systemd/system/xvnc@.service|<br />
<nowiki><br />
[Unit]<br />
Description=XVNC Per-Connection Daemon<br />
<br />
[Service]<br />
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1920x1080 -once -SecurityTypes=None<br />
User=nobody<br />
StandardInput=socket<br />
StandardError=syslog<br />
</nowiki>}}<br />
Use systemctl to [[start]] and [[enable]] {{ic|xvnc.socket}}. Now any number of users can get unique desktops by connecting to port 5900.<br />
<br />
If the VNC server is exposed to the internet, add the {{ic|-localhost}} option to {{ic|Xvnc}} in {{ic|xvnc@.service}} and follow the instructions below about connecting over SSH (Note that the 'localhost' in {{ic|-query localhost}} is not {{ic|-localhost}}). Since we only select a user after connecting, the VNC server runs as user 'nobody' and uses xvnc directly instead of the 'vncserver' script, so any options in ~/.vnc are ignored. Optionally [[autostart]] {{ic|vncconfig}} so that the clipboard works ({{ic|vncconfig}} exits immediately in non-VNC sessions). One way is to create:<br />
{{hc|/etc/X11/xinit/xinitrc.d/99-vncconfig.sh|<br />
<nowiki><br />
#!/bin/sh<br />
vncconfig -nowin &<br />
</nowiki>}}<br />
<br />
== Running vncserver to directly control the local display ==<br />
<br />
=== Using tigervnc's x0vncserver ===<br />
{{Pkg|tigervnc}} provides the x0vncserver binary which allows direct control over a physical X session. Invoke it like so:<br />
$ x0vncserver -display :0 -passwordfile ~/.vnc/passwd<br />
<br />
For more see<br />
man x0vncserver<br />
<br />
==== Starting and stopping x0vncserver via systemd ====<br />
<br />
{{Warning|Do not run this service if your local area network is untrusted!}}<br />
<br />
In order to have a VNC Server runnning x0vncserver, which is the easiest way for most users to quickly have remote access to the current desktop, you can create a systemd unit.<br />
<br />
{{Note|This unit will only be useful if the user in the unit is currently running a X session.}}<br />
<br />
Create {{ic|/etc/systemd/system/x0vncserver.service}} and modify it defining the user to run the server, and the desired options.<br />
<br />
{{hc|/etc/systemd/system/x0vncserver.service|<br />
<nowiki><br />
[Unit]<br />
Description=Remote desktop service (VNC)<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
User=foo<br />
ExecStart=/usr/bin/sh -c '/usr/bin/x0vncserver -display :0 -rfbport 5900 -passwordfile /home/foo/.vnc/passwd &'<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
=== Using x11vnc ===<br />
Another option is to use {{pkg|x11vnc}} which has the advantage or disadvantage, depending on one's perspective, of requiring root to initiate the access. For more, see: [[X11vnc]].<br />
<br />
== Connecting to vncserver ==<br />
{{Warning|It is ill-advised to connect insecurely to a vncserver outside of the LAN; readers are encouraged read the rest of this article in its entirety if use cases require connections outside of one's LAN. That being said, TigerVNC ''is encrypted by default'' unless it is specifically instructed otherwise by setting SecurityTypes to a non-secure option, although this lacks identity verification and will not prevent MITM attack during the connection setup. X509Vnc is the recommended option for a secure connection.}}<br />
<br />
Any number of clients can connect to a vncserver. A simple example is given below where vncserver is running on 10.1.10.2 on port 5901 (:1) in shorthand notation:<br />
$ vncviewer 10.1.10.2:1<br />
<br />
=== Passwordless authentication ===<br />
<br />
The {{ic|-passwd}} switch allows one to define the location of the server's {{ic|~/.vnc/passwd}} file. It is expected that the user has access to this file on the server through [[SSH]] or through physical access. In either case, place that file on the client's file system in a safe location, i.e. one that has read access ONLY to the expected user.<br />
<br />
$ vncviewer -passwd /path/to/server-passwd-file<br />
<br />
=== Example GUI-based clients ===<br />
<br />
* {{Pkg|gtk-vnc}}<br />
* {{Pkg|krdc}}<br />
* {{Pkg|rdesktop}}<br />
* {{Pkg|vinagre}}<br />
* {{Pkg|remmina}}<br />
* {{Pkg|vncviewer-jar}}<br />
<br />
TigerVNC's vncviewer also has a simple GUI when run without any parameters:<br />
$ vncviewer<br />
<br />
== Accessing vncserver via SSH tunnels ==<br />
An advantage of SSH tunneling is one does not need to open up another port to the outside, since the traffic is literally tunneled through the SSH port which the user already has open to the WAN. It is highly recommended to use the {{ic|-localhost}} switch when running vncserver with this method since this switch only allows connections ''from the localhost'' and by analogy, only by users physically ssh'ed and authenticated on the box.<br />
<br />
{{Note|TigerVNC uses TLSVnc encryption by default, unless specifically instructed via the SecurityTypes parameter. Authentication and traffic is encrypted, but there is no identity verification. TigerVNC supports alternative encryption schemes such as X509Vnc that allows the client to verify the identity of the server.<br />
<br />
When the SecurityTypes on the server side is set to a non-secure option as high-priority (such as None, VncAuth, Plain, TLSNone, TLSPlain, X509None, X509Plain; which is ill-advised), it is not possible to use encryption. In that case, one can tunnel the VNC over SSH. When running vncviewer, it is a good idea to explicitly set SecurityTypes and not accept any unencrypted traffic.}}<br />
<br />
=== On the server ===<br />
Below is an example invoking vncserver with the -localhost flag:<br />
$ vncserver -geometry 1440x900 -alwaysshared -dpi 96 -localhost :1<br />
<br />
Alternatively, simply add the "localhost" option as a single line in {{ic|~/.vnc/config}}. Below is the example above in this format:<br />
{{hc|~/.vnc/config|<br />
<nowiki><br />
## Supported server options to pass to vncserver upon invocation can be listed<br />
## in this file. See the following manpages for more: vncserver(1) Xvnc(1).<br />
## Several common ones are shown below. Uncomment and modify to your liking.<br />
##<br />
geometry=1200x700<br />
alwaysshared<br />
dpi=96<br />
localhost<br />
</nowiki>}}<br />
<br />
=== On the client ===<br />
<br />
With the server now only accepting connection from the localhost, connect to the box via ssh using X-forwarding and the -L switch to enable tunnels. For more on this feature, see the manpage for ssh itself.<br />
For example:<br />
<br />
$ ssh -X 10.1.10.2 -L 5901:localhost:5901<br />
<br />
This forwards the server port 5901 to the client box also on port 5901. Note that one does not have to match the port numbers on the server and client. For example:<br />
<br />
$ ssh -X 10.1.10.2 -L 8900:localhost:5901<br />
<br />
This forwards the server port 5901 to the client box on port 8900. <br />
<br />
Once connected via SSH, leave that xterm or shell window open since it is acting as the secured tunnel to/from server. To connect via this encrypted tunnel, simply point the vncviewer to the client port on the localhost.<br />
<br />
Using the matched ports on the server/client:<br />
$ vncviewer localhost:5901<br />
<br />
Using different ports on the server/client:<br />
$ vncviewer localhost:8900<br />
<br />
=== Connecting to a vncserver from Android devices over SSH ===<br />
<br />
To connect to a VNC Server over SSH using an Android device:<br />
<br />
{{bc|1. SSH server running on the machine to connect to.<br />
2. VNC server running on the machine to connect to. (Run server with -localhost flag as mentioned above)<br />
3. SSH client on the Android device (ConnectBot is a popular choice and will be used in this guide as an example).<br />
4. VNC client on the Android device (androidVNC).}}<br />
<br />
Consider some dynamic DNS service for targets that do not have static IP addresses.<br />
<br />
In ConnectBot, type in the IP and connect to the desired machine. Tap the options key, select Port Forwards and add a new port:<br />
<br />
{{bc|Nickname: vnc<br />
Type: Local<br />
Source port: 5901<br />
Destination: 127.0.0.1:5901}}<br />
<br />
Save that.<br />
<br />
In androidVNC:<br />
<br />
{{bc|Nickname: nickname<br />
Password: the password used to set up the VNC server<br />
Address: 127.0.0.1 (we are in local after connecting through SSH)<br />
Port: 5901}}<br />
<br />
Connect.<br />
<br />
== Tips and tricks ==<br />
=== Connecting to an OSX system ===<br />
<br />
See https://help.ubuntu.com/community/AppleRemoteDesktop. Tested with Remmina.<br />
<br />
=== Connecting to non-X environments on a Raspberry Pi (Arch ARM) ===<br />
Install {{AUR|dispmanx_vnc}} on the Arch ARM device. Frame rates are not very high but it provides a working VNC access.<br />
<br />
=== Copying clipboard contents from the remote machine to the local ===<br />
<br />
If copying from the remote machine to the local machine does not work, run autocutsel on the server, as mentioned below [https://bbs.archlinux.org/viewtopic.php?id=101243 reference]:<br />
<br />
$ autocutsel -fork<br />
<br />
Now press F8 to display the VNC menu popup, and select {{ic|Clipboard: local -> remote}} option.<br />
<br />
One can put the above command in {{ic|~/.vnc/xstartup}} to have it run automatically when vncserver is started.<br />
<br />
=== Fix for no mouse cursor ===<br />
<br />
If no mouse cursor is visible when using {{ic|x0vncserver}}, start vncviewer as follows:<br />
<br />
$ vncviewer DotWhenNoCursor=1 <server><br />
<br />
Or put {{ic|DotWhenNoCursor<nowiki>=</nowiki>1}} in the tigervnc configuration file, which is at {{ic|~/.vnc/default.tigervnc}} by default.<br />
<br />
=== Recommended security settings ===<br />
{{Note|If using ssh tunnels (i.e. [[#Accessing vncserver via SSH tunnels]]), X509Vnc is not required since the encryption is handled by the sshd.}}<br />
<br />
SecurityTypes controls the preferred security algorithms. The default in the current version 1.5.0 is "X509Plain,TLSPlain,X509Vnc,TLSVnc,X509None,TLSNone,VncAuth,None". A more secure alternative is "X509Vnc,TLSVnc", which will disable all unencrypted data traffic.<br />
<br />
It is recommended to use X509Vnc, as TLSVnc lacks identity verification.<br />
<br />
$ vncserver -x509key /path/to/key.pem -x509cert /path/to/cerm.pem -SecurityTypes X509Vnc :1<br />
<br />
Issuing x509 certificates is beyond the scope of this guide. However, this is expected to be straightforward after the public launch of [[wikipedia:Let's Encrypt|Let's Encrypt]]. Alternatively, one can issue certificates using [[OpenSSL]] and manually share the keys between server and client using email for instance.<br />
<br />
=== Toggling Fullscreen ===<br />
<br />
This can be done through vncclient's Menu. By default, vncclient's Menu Key is F8.<br />
<br />
=== Unable to type less than character (<) ===<br />
If pressing {{ic|<}} on a remote client emits the {{ic|>}} character, try remapping the incoming key [https://insaner.com/blog/2013/05.html#20130422063137]:<br />
<br />
$ x0vncserver -RemapKeys="0x3c->0x2c"</div>Phil.r.dubois