https://wiki.archlinux.org/api.php?action=feedcontributions&user=Jussihi&feedformat=atomArchWiki - User contributions [en]2024-03-28T22:30:32ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=627346Unified Extensible Firmware Interface/Secure Boot2020-07-31T10:13:55Z<p>Jussihi: /* Booting an installation medium */ Added the option to remaster the installation media with already signed shim+grub from another distro. Please fix any typos/formatting errors.</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]<br />
{{Expansion|Need to explain the relationship with Win8 which is already documented in [[Dual boot with Windows#UEFI Secure Boot]]. Not sure how to integrate the info without duplication.}}<br />
{{Related articles start}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
For an overview about Secure Boot in Linux see [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article. This article focuses on how to set up Secure Boot in Arch Linux. <br />
<br />
{{Accuracy|Secure Boot is in no way related to LUKS. Secure Boot has dbx for blacklisting keys and hashes. Using a unified kernel image signed with a custom key, althought the most secure, is not the only way to use Secure Boot.}}<br />
<br />
''Secure Boot'' is a security feature of modern motherboards, which can protect boot manager, kernel and initramfs from tampering: e.g. from installing an keylogger or bootkit able to steal your LUKS master key. Minimal configuration in which using ''Secure boot'' worth time spent:<br />
<br />
# UEFI considered trusted, despite it still can have backdoors or being vulnerable to Evil Maid able to flash your hardware<br />
# User ''must not'' use 3rd party keys, especially from Microsoft (there is at least one known boot manager, signed by Microsoft, able to load anything [https://habr.com/ru/post/446238/])<br />
# UEFI loads [[EFISTUB]] with ''both'' kernel+initram signed by user ''Image Signing Key'', so no one can tamper it<br />
# Kernel mounts encrypted root and home filesystems ([[dm-crypt/Encrypting an entire system#LVM on LUKS|LVM on LUKS]]), so no one can tamper them, read mentioned private keys, password hashes or user sensitive data<br />
<br />
In future, Evil Maid attack can be potentially prevented by using a [[TPM]].<br />
<br />
== Secure Boot status ==<br />
<br />
=== Check the status ===<br />
==== Before booting the OS ====<br />
<br />
At this point, one has to look at the firmware setup. If the machine was booted and is running, in most cases it will have to be rebooted. <br />
<br />
You may access the firmware configuration by pressing a special key during the boot process. The key to use depends on the firmware. It is usually one of {{ic|Esc}}, {{ic|F2}}, {{ic|Del}} or possibly another {{ic|F''n''}} key. Sometimes the right key is displayed for a short while at the beginning of the boot process. The motherboard manual usually records it. You might want to press the key, and keep pressing it, immediately following powering on the machine, even before the screen actually displays anything.<br />
<br />
After entering the firmware setup, be careful not to change any settings without prior intention. Usually there are navigation instructions, and short help for the settings, at the bottom of each setup screen. The setup itself might be composed of several pages. You will have to navigate to the correct place. The interesting setting might be simply denoted by secure boot, which can be set on or off.<br />
<br />
==== After booting the OS ====<br />
To check if the machine was booted with Secure Boot, use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
<br />
If Secure Boot is enabled, this command returns {{ic|1}} as the final integer in a list of five, for example:<br />
<br />
6 0 0 0 1<br />
<br />
For a verbose status, another way is to execute:<br />
<br />
$ bootctl status<br />
<br />
=== Change the status ===<br />
{{Expansion|Layout quick steps how an Arch install can gain Secure Boot with either [[#Using a signed boot loader]] or [[#Using your own keys]]. In the steps it is best mentioned that the structure of those two sections relies on having booted into Arch, i.e. [[#Disable Secure Boot]] first.}}<br />
<br />
== Using a signed boot loader ==<br />
<br />
Using a signed boot loader means using a boot loader signed with Microsoft's key. There are two known signed boot loaders PreLoader and shim, their purpose is to chainload other EFI binaries (usually [[boot loader]]s). Since Microsoft would never sign a boot loader that automatically launches any unsigned binary, PreLoader and shim use a whitelist called Machine Owner Key list, abbreviated MokList. If the SHA256 hash of the binary (Preloader and shim) or key the binary is signed with (shim) is in the MokList they execute it, if not they launch a key management utility which allows enrolling the hash or key.<br />
<br />
=== PreLoader ===<br />
<br />
When run, PreLoader tries to launch {{ic|loader.efi}}. If the hash of {{ic|loader.efi}} is not in MokList, PreLoader will launch {{ic|HashTool.efi}}. In HashTool you must enroll the hash of the EFI binaries you want to launch, that means your [[boot loader]] ({{ic|loader.efi}}) and kernel.<br />
<br />
{{Note|Each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash.}}<br />
<br />
{{Tip|The [[rEFInd]] boot manager's {{ic|refind-install}} script can copy the rEFInd and PreLoader EFI binaries to the ESP. See [[rEFInd#Using PreLoader]] for instructions.}}<br />
<br />
==== Set up PreLoader ====<br />
<br />
{{Note|{{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} package are not signed, so their usefulness is limited. You can get a signed {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually].}}<br />
<br />
[[Install]] {{AUR|preloader-signed}} and copy {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} to the [[boot loader]] directory; for [[systemd-boot]] use:<br />
<br />
# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd<br />
<br />
Now copy over the boot loader binary and rename it to {{ic|loader.efi}}; for [[systemd-boot]] use:<br />
<br />
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi<br />
<br />
Finally, create a new NVRAM entry to boot {{ic|PreLoader.efi}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi<br />
<br />
Replace {{ic|''X''}} with the drive letter and replace {{ic|''Y''}} with the partition number of the [[EFI system partition]].<br />
<br />
This entry should be added to the list as the first to boot; check with the {{ic|efibootmgr}} command and adjust the boot-order if necessary.<br />
<br />
===== Fallback =====<br />
<br />
If there are problems booting the custom NVRAM entry, copy {{ic|HashTool.efi}} and {{ic|loader.efi}} to the default loader location booted automatically by UEFI systems:<br />
<br />
# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/Boot<br />
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/Boot/loader.efi<br />
<br />
Copy over {{ic|PreLoader.efi}} and rename it:<br />
<br />
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Boot/bootx64.efi<br />
<br />
For particularly intransigent UEFI implementations, copy {{ic|PreLoader.efi}} to the default loader location used by Windows systems:<br />
<br />
# mkdir -p ''esp''/EFI/Microsoft/Boot<br />
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi<br />
<br />
{{Note|If dual-booting with Windows, backup the original {{ic|bootmgfw.efi}} first as replacing it may cause problems with Windows updates.}}<br />
<br />
As before, copy {{ic|HashTool.efi}} and {{ic|loader.efi}} to {{ic|''esp''/EFI/Microsoft/Boot/}}.<br />
<br />
When the system starts with Secure Boot enabled, follow the steps above to enroll {{ic|loader.efi}} and {{ic|/vmlinuz-linux}} (or whichever kernel image is being used).<br />
<br />
==== How to use while booting? ====<br />
<br />
A message will show up that says {{ic|Failed to Start loader... I will now execute HashTool.}} To use HashTool for enrolling the hash of {{ic|loader.efi}} and {{ic|vmlinuz.efi}}, follow these steps. These steps assume titles for a remastered archiso installation media. The exact titles you will get depends on your boot loader setup.<br />
<br />
* Select ''OK''<br />
* In the HashTool main menu, select ''Enroll Hash'', choose {{ic|\loader.efi}} and confirm with ''Yes''. Again, select ''Enroll Hash'' and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz.efi}} and confirm with ''Yes''. Then choose ''Exit'' to return to the boot device selection menu.<br />
* In the boot device selection menu choose ''Arch Linux archiso x86_64 UEFI CD''<br />
<br />
==== Remove PreLoader ====<br />
<br />
{{Note|Since you are going to remove stuff, is a good idea to backup it.}}<br />
<br />
[[Uninstall]] {{AUR|preloader-signed}} and simply remove the copied files and revert configuration; for [[systemd-boot]] use:<br />
<br />
# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi<br />
# rm ''esp''/EFI/systemd/loader.efi<br />
# efibootmgr --verbose --bootnum ''N'' --delete-bootnum<br />
# bootctl update<br />
<br />
Where {{ic|''N''}} is the NVRAM boot entry created for booting {{ic|PreLoader.efi}}.<br />
Check with the ''efibootmgr'' command and adjust the boot-order if necessary.<br />
<br />
{{Note|The above commands cover the easiest case; if you have created, copied, renamed or edited further files probably you have to handle with them, too. If PreLoader was your operational boot entry, you obviously also need to [[#Disable Secure Boot]].}}<br />
<br />
=== shim ===<br />
<br />
{{Expansion|Testing needed.|section=shim}}<br />
<br />
When run, shim tries to launch {{ic|grubx64.efi}}. If MokList does not contain the hash of {{ic|grubx64.efi}} or the key it is signed with, shim will launch MokManager ({{ic|mmx64.efi}}). In MokManager you must enroll the hash of the EFI binaries you want to launch (your [[boot loader]] ({{ic|grubx64.efi}}) and kernel) or enroll the key they are signed with.<br />
<br />
{{Note|If you use [[#shim with hash]], each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash.}}<br />
<br />
==== Set up shim ====<br />
<br />
{{Tip|The [[rEFInd]] boot manager's {{ic|refind-install}} script can sign rEFInd EFI binaries and copy them along with shim and the MOK certificates to the ESP. See [[rEFInd#Using shim]] for instructions.}}<br />
<br />
[[Install]] {{AUR|shim-signed}}.<br />
<br />
Rename your current [[boot loader]] to {{ic|grubx64.efi}}<br />
<br />
# mv ''esp''/EFI/BOOT/BOOTX64.efi ''esp''/EFI/BOOT/grubx64.efi<br />
<br />
Copy ''shim'' and ''MokManager'' to your boot loader directory on ESP; use previous filename of your boot loader as as the filename for {{ic|shimx64.efi}}:<br />
<br />
# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTX64.efi<br />
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/<br />
<br />
''shim'' can authenticate binaries by Machine Owner Key or hash stored in MokList.<br />
<br />
; Machine Owner Key (MOK): A key that a user generates and uses to sign EFI binaries.<br />
; hash: A SHA256 hash of an EFI binary.<br />
<br />
Using hash is simpler, but each time you update your boot loader or kernel you will need to add their hashes in MokManager. With MOK you only need to add the key once, but you will have to sign the boot loader and kernel each time it updates.<br />
<br />
===== shim with hash =====<br />
<br />
If ''shim'' does not find the SHA256 hash of {{ic|grubx64.efi}} in MokList it will launch MokManager ({{ic|mmx64.efi}}).<br />
<br />
In ''MokManager'' select ''Enroll hash from disk'', find {{ic|grubx64.efi}} and add it to MokList. Repeat the steps and add your kernel {{ic|vmlinuz-linux}}. When done select ''Continue boot'' and your boot loader will launch and it will be capable launching the kernel.<br />
<br />
===== shim with key =====<br />
<br />
Install {{Pkg|sbsigntools}}.<br />
<br />
You will need:<br />
<br />
; ''.key'': PEM format '''private''' key for EFI binary signing.<br />
; ''.crt'': PEM format certificate for ''sbsign''.<br />
; ''.cer'': DER format certificate for ''MokManager''.<br />
<br />
Create a Machine Owner Key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt<br />
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer<br />
<br />
Sign your boot loader (named {{ic|grubx64.efi}}) and kernel:<br />
<br />
# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi<br />
<br />
You will need to do this each time they are updated. You can automate the kernel signing with a [[pacman hook]], e.g.:<br />
<br />
{{hc|/etc/pacman.d/hooks/999-sign_kernel_for_secureboot.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Type = Package<br />
Target = linux<br />
<br />
[Action]<br />
Description = Signing kernel with Machine Owner Key for Secure Boot<br />
When = PostTransaction<br />
Exec = /usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null {{!}} /usr/bin/grep -q "signature certificates"; then /usr/bin/sbsign --key MOK.key --cert MOK.crt --output {} {}; fi' ;<br />
Depends = sbsigntools<br />
Depends = findutils<br />
Depends = grep<br />
}}<br />
<br />
Copy {{ic|MOK.cer}} to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
Reboot and enable Secure Boot. If ''shim'' does not find the certificate {{ic|grubx64.efi}} is signed with in MokList it will launch MokManager ({{ic|mmx64.efi}}).<br />
<br />
In ''MokManager'' select ''Enroll key from disk'', find {{ic|MOK.cer}} and add it to MokList. When done select ''Continue boot'' and your boot loader will launch and it will be capable launching any binary signed with your Machine Owner Key.<br />
<br />
====== shim with key and GRUB ======<br />
<br />
{{Style|Too long, written like a blog post. Also many formatting issues, see [[Help:Style]].}}<br />
<br />
{{Warning|With secureboot active GRUB can't chainload EFI binaries even if they are signed.}}<br />
<br />
For signing you can for example use the grub2-signing extension:<br />
[https://github.com/Bandie/grub2-signing-extension]<br />
<br />
There is also a package in the aur: {{AUR|grub2-signing-extension}}<br />
<br />
<br />
Run {{ic|gpg --gen-key}} as root to create a keypair.<br />
<br />
If you get a permission denied error try:<br />
# chown root:root $(tty)<br />
# export GPG_TTY"="$(tty)<br />
<br />
Activate the gpg-agent:<br />
{{hc| /root/.gnupg/gpg.conf | use-agent }}<br />
<br />
{{hc| /root/.gnupg/gpg-agent.conf |<br />
pinentry-program /usr/bin/pinentry<br />
no-grab<br />
default-cache-ttl 1800<br />
}}<br />
<br />
Export your public key:<br />
{{bc|gpg --export -o ~/pubkey}}<br />
<br />
Mount your boot partition.<br />
(Re)install GRUB2:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB -k /root/pubkey --modules="gcry_sha256 gcry_dsa gcry_rsa"<br />
<br />
Copy your publickey to your boot partiton.<br />
{{bc|cp /root/pubkey /boot/pubkey}}<br />
<br />
<br />
Edit your GRUB custom config and add:<br />
{{hc|1=/etc/grub.d/40_Custom|2=insmod verify<br />
insmod gcry_sha256<br />
insmod gcry_dsa gcry_rsa<br />
set check_signatures=enforce<br />
trust (crypto0)/pubkey<br />
insmod shim_lock}}<br />
<br />
{{Tip|(crypt0) is the name of the partition in GRUB.}}<br />
<br />
<br />
Rebuild your grub config:<br />
{{bc|grub-mkconfig > /boot/grub/grub.cfg}}<br />
<br />
Ensure that you created {{ic|MOK.key}} and signed your {{ic|kernel}} and {{ic|grubx64.efi}} like <br />
described in '''shim with key'''.<br />
<br />
<br />
Sign the grub files: {{ic|grub-sign}}<br />
<br />
Run {{ic|grub-verify}} and check if there are errors.<br />
<br />
Here is a simple unsign hook:<br />
{{hc|10-unsign-grub-before-update.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Type = Package<br />
Target = linux<br />
Target = linux-lts<br />
Target = linux-zen<br />
Target = grub<br />
Target = intel-ucode<br />
Target = amd-ucode<br />
<br />
[Action]<br />
Description = Unsigning GRUB<br />
When = PreTransaction<br />
Exec = /usr/bin/grub-unsign<br />
}}<br />
<br />
And a bash script you can use to sign again after the update.<br />
<br />
{{hc| .bashrc|<br />
function sign-update () {<br />
/usr/bin/grub-unsign<br />
if [ $? -ne 0 ]; then return 1; fi<br />
/usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -not -name "*.sig" -exec /usr/bin/sh -c \<br />
'if ! /usr/bin/sbverify --list {} 2>/dev/null {{!}} /usr/bin/grep -q "signature certificates"; \<br />
then echo "Signing with sbsign."; /usr/bin/sbsign --key MOK.key --cert MOK.crt --output {} {}; fi' \;<br />
/usr/bin/grub-sign<br />
/usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -not -name "*.sig" -exec /usr/bin/sh -c \<br />
'echo ""; echo {}; /usr/bin/sbverify --list {};' \;<br />
}<br />
}}<br />
<br />
==== Remove shim ====<br />
<br />
[[Uninstall]] {{AUR|shim-signed}}, remove the copied ''shim'' and ''MokManager'' files and rename back your boot loader.<br />
<br />
== Using your own keys ==<br />
<br />
{{Expansion|instructions needed, testing too, a subsection on backing up existing keys prior to replacing them should be added}}<br />
<br />
{{Tip|<br />
* It is advised to read [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot].<br />
* You can use {{ic|cryptboot-efikeys}} script from {{AUR|cryptboot}} package for simplified creating keys, enrolling keys, signing bootloader and verifying signatures.<br />
** Note that {{AUR|cryptboot}} requires the encrypted {{ic|/boot}} partition to be specified in {{ic|/etc/crypttab}} before it runs, and if you are using it in combination with {{AUR|sbupdate-git}}, ''sbupdate'' expects the {{ic|/boot/efikeys/db.*}} files created by ''cryptboot'' to be capitalized like {{ic|DB.*}} unless otherwise configured in {{ic|/etc/sbupdate.conf}}. Users who do not use systemd to handle encryption may not have anything in their {{ic|/etc/crypttab}} file and would need to create an entry.<br />
}}<br />
<br />
Secure Boot implementations use these keys:<br />
<br />
; Platform Key (PK): Top-level key.<br />
; Key Exchange Key (KEK): Keys used to sign Signatures Database and Forbidden Signatures Database updates.<br />
; Signature Database (db): Contains keys and/or hashes of allowed EFI binaries.<br />
; Forbidden Signatures Database (dbx): Contains keys and/or hashes of blacklisted EFI binaries.<br />
<br />
See [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] for a more detailed explanation.<br />
<br />
=== Custom keys ===<br />
<br />
To use Secure Boot you need at least '''PK''', '''KEK''' and '''db''' keys. While you can add multiple KEK, db and dbx certificates, only one Platform Key is allowed.<br />
<br />
Once Secure Boot is in "User Mode" keys can only be updated by signing the update (using ''sign-efi-sig-list'') with a higher level key. Platform key can be signed by itself.<br />
<br />
==== Creating keys ====<br />
<br />
To generate keys, [[install]] {{Pkg|efitools}} and perform the following steps. As an alternative, install and run {{AUR|sbkeys}} to generate a new set of keys automatically.<br />
<br />
You will need private keys and certificates in multiple formats:<br />
<br />
; ''.key'': PEM format '''private''' keys for EFI binary and EFI signature list signing.<br />
; ''.crt'': PEM format certificates for {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and firmware.<br />
<br />
Create a [[Wikipedia:Globally unique identifier|GUID]] for owner identification:<br />
<br />
$ uuidgen --random > GUID.txt<br />
<br />
Platform key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt<br />
$ openssl x509 -outform DER -in PK.crt -out PK.cer<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth<br />
<br />
Sign an empty file to allow removing Platform Key when in "User Mode":<br />
<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null rm_PK.auth<br />
<br />
Key Exchange Key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt<br />
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth<br />
<br />
Signature Database key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt<br />
$ openssl x509 -outform DER -in db.crt -out db.cer<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth<br />
<br />
==== Updating keys ====<br />
<br />
Once Secure Boot is in "User Mode" any changes to KEK, db and dbx need to be signed with a higher level key.<br />
<br />
For example, if you wanted to replace your db key with a new one:<br />
<br />
# [[#Creating keys|Create the new key]],<br />
# Convert it to EFI Signature List,<br />
# Sign the EFI Signature List,<br />
# Enroll the signed certificate update file.<br />
<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth<br />
<br />
If instead of replacing your db key, you want to '''add''' another one to the Signature Database, you need to use the option {{ic|-a}} (see {{man|1|sign-efi-sig-list}}):<br />
<br />
$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth<br />
<br />
When {{ic|''new_db''.auth}} is created, [[#Enroll keys in firmware|enroll it]].<br />
<br />
=== Signing EFI binaries ===<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched. Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* The [[rEFInd]] boot manager's {{ic|refind-install}} script can sign rEFInd EFI binaries and copy them together with the db certificates to the ESP. See [[rEFInd#Using your own keys]] for instructions.<br />
}}<br />
<br />
{{Note|If running ''sbsign'' without {{ic|--output}} the resulting file will be {{ic|''filename''.signed}}. See {{man|1|sbsign}} for more information.}}<br />
<br />
==== Signing the kernel and boot manager ====<br />
<br />
{{Warning|Signing kernel only will not protect the initramfs from tampering.}}<br />
<br />
To sign your kernel and boot manager use ''sbsign''. E.g.:<br />
<br />
# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux<br />
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTX64.EFI ''esp''/EFI/BOOT/BOOTX64.EFI<br />
<br />
===== Signing the kernel with a pacman hook =====<br />
<br />
You can also use mkinitcpio's [[pacman hook]] to sign the kernel on install and updates.<br />
<br />
Copy {{ic|/usr/share/libalpm/hooks/90-mkinitcpio-install.hook}} to {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}} and {{ic|/usr/share/libalpm/scripts/mkinitcpio-install}} to {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}.<br />
<br />
In {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}}, replace:<br />
<br />
Exec = /usr/share/libalpm/scripts/mkinitcpio-install<br />
<br />
with:<br />
<br />
Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install<br />
<br />
In {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}, replace:<br />
<br />
install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"<br />
<br />
with:<br />
<br />
sbsign --key ''/path/to/''db.key --cert ''/path/to/''db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"<br />
<br />
{{Move|systemd-boot|Out of scope.}}<br />
<br />
If you need a boot manager, you might want to trigger the hook when the former is updated. Here is an example with systemd-boot:<br />
<br />
{{hc|/etc/pacman.d/hooks/99-secureboot.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Type = Package<br />
Target = linux<br />
Target = systemd<br />
<br />
[Action]<br />
Description = Signing Kernel for SecureBoot<br />
When = PostTransaction<br />
Exec = /usr/bin/sh -c "/usr/bin/find /boot/ -type f \( -name 'vmlinuz-*' -o -name 'systemd*' \) -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null {{!}} /usr/bin/grep -q \"signature certificates\"; then /usr/bin/sbsign --key db.key --cert db.crt --output {} {}; fi' \;"<br />
Depends = sbsigntools<br />
Depends = findutils<br />
Depends = grep<br />
}}<br />
<br />
The {{ic|Target}} needs to be duplicated each time you want to add a new package. Wrt. the {{ic|find}} statement, since we had a condition with the filenames and APLM hooks are being split on spaces, we had to surround the whole statement by quotes in order for the hook to be parsed properly. Since systemd-boot is located in sub-folders, the depth needed to be adjusted as well so that we removed the {{ic|-maxdepth}} argument. In order to avoid hassle, if you are unsure, try to reinstall the package you want to test to see if the hook and signing part are processed successfully. See [[Pacman#Hooks]] or {{man|5|alpm-hooks}} for more info.<br />
<br />
=== Put firmware in "Setup Mode" ===<br />
<br />
Secure Boot is in Setup Mode when the Platform Key is removed. To put firmware in Setup Mode, enter firmware setup utility and find an option to delete or clear certificates. How to enter the setup utility is described in [[#Before booting the OS]].<br />
<br />
=== Enroll keys in firmware ===<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
Launch firmware setup utility or KeyTool and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<br />
<br />
{{Warning|Enrolling Platform Key sets Secure Boot in "User Mode", leaving "Setup Mode", so it should be enrolled last in sequence.}}<br />
<br />
==== Using firmware setup utility ====<br />
<br />
Firmwares have various different interfaces, see [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] for example how to enroll keys.<br />
<br />
==== Using KeyTool ====<br />
<br />
{{ic|KeyTool.efi}} is in {{Pkg|efitools}} package, copy it to ESP. To use it after enrolling keys, sign it with {{ic|sbsign}}.<br />
<br />
# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi<br />
<br />
Launch {{ic|KeyTool-signed.efi}} using firmware setup utility, boot loader or [[Unified Extensible Firmware Interface#UEFI Shell|UEFI Shell]] and enroll keys.<br />
<br />
See [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] for explanation of KeyTool menu options.<br />
<br />
=== Dual booting with other operating systems ===<br />
<br />
==== Microsoft Windows ====<br />
<br />
{{Expansion|Is it possible to boot Windows by signing its bootloader with a [[#Creating keys|custom key]]?}}<br />
<br />
To [[dual boot with Windows]], you would need to add Microsoft's certificates to the Signature Database. [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has two db certificates]:<br />
<br />
* [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011] for Windows<br />
* [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011] for third-party binaries like UEFI drivers, option ROMs etc.<br />
<br />
Create EFI Signature Lists from Microsoft's DER format certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Sign a db update with your KEK. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a db certificate:<br />
<br />
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth<br />
<br />
Follow [[#Enroll keys in firmware]] to add {{ic|add_MS_db.auth}} to Signature Database.<br />
<br />
== Disable Secure Boot ==<br />
<br />
The Secure Boot feature can be disabled via the UEFI firmware interface. How to access the firmware configuration is described in [[#Before booting the OS]].<br />
<br />
If using a hotkey did not work and you can boot Windows, you can force a reboot into the firmware configuration in the following way (for Windows 10): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''.<br />
<br />
Note that some motherboards (this is the case in a Packard Bell laptop) only allow to disable secure boot if you have set an administrator password (that can be removed afterwards). See also [http://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disable Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
One might want to [[Remastering the Install ISO|remaster the Install ISO]] in a way described by previous topics of this article. For example, the signed EFI applications {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from [[#PreLoader]] can be adopted to here. Another option would be to borrow the {{ic|bootx64.efi}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ( [https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. Note that up to this point, the article assumed one can access the [[ESP]] of the machine. But when installing a machine that never had an OS before, there is no ESP present. You should explore other articles, for example [[Unified Extensible Firmware Interface#Create UEFI bootable USB from ISO]], to learn how this situation should be handled.<br />
<br />
== Platform configuration registers ==<br />
<br />
{{Expansion|Add some links.}}<br />
<br />
Platform configuration registers (PCRs) are hashes that can be read at any time but can only be written via the extend operation, which depends on the previous hash value, thus making a sort of blockchain.<br />
<br />
They can be used to unlock encryption keys and proving that the correct OS was booted.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| PCR<br />
! scope="col"| Use<br />
! scope="col"| Notes<br />
|-<br />
|PCR0<br />
|Core System Firmware executable code (aka Firmware)<br />
|May change if you upgrade your UEFI<br />
|-<br />
|PCR1<br />
|Core System Firmware data (aka UEFI settings)<br />
|<br />
|-<br />
|PCR2<br />
|Extended or pluggable executable code<br />
|<br />
|-<br />
|PCR3<br />
|Extended or pluggable firmware data<br />
|Set during Boot Device Select UEFI boot phase<br />
|-<br />
|PCR4<br />
|Boot Manager<br />
|<br />
|-<br />
|PCR5<br />
|GPT / Partition Table<br />
|<br />
|-<br />
|PCR6<br />
|Resume from S4 and S5 Power State Events<br />
|<br />
|-<br />
|PCR7<br />
|Secure Boot State<br />
|<br />
|-<br />
|PCR 8 to 10<br />
|Reserved for Future Use<br />
|<br />
|-<br />
|PCR11<br />
|BitLocker Access Control<br />
|<br />
|-<br />
|PCR12<br />
|Data events and highly volatile events<br />
|<br />
|-<br />
|PCR13<br />
|Boot Module Details<br />
|<br />
|-<br />
|PCR14<br />
|Boot Authorities<br />
|<br />
|-<br />
|PCR 15 to 23<br />
|Reserved for Future Use<br />
|<br />
|}<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] by Rod Smith<br />
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] by Matthew Garrett<br />
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] by James Bottomley<br />
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]<br />
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation<br />
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Free Software Foundation recommendations for free operating system distributions considering Secure Boot]<br />
* [https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]{{Dead link|2020|04|03|status=404}}<br />
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] by NSA - National Security Agency</div>Jussihihttps://wiki.archlinux.org/index.php?title=SELinux&diff=577547SELinux2019-07-17T07:02:15Z<p>Jussihi: Fix renamed AUR package (libsystemd-selinux --> systemd-libs-selinux)</p>
<hr />
<div>[[Category:Access control]]<br />
[[Category:Kernel]]<br />
[[Category:Red Hat]]<br />
[[ja:SELinux]]<br />
[[ru:SELinux]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|AppArmor}}<br />
{{Related|TOMOYO Linux}}<br />
{{Related articles end}}<br />
<br />
Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style [[Mandatory Access Control]] (MAC), through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.<br />
<br />
Running SELinux under a Linux distribution requires three things: An SELinux enabled kernel, SELinux Userspace tools and libraries, and SELinux Policies (mostly based on the Reference Policy). Some common Linux programs will also need to be patched/compiled with SELinux features.<br />
<br />
==Current status in Arch Linux==<br />
<br />
SELinux is not officially supported (see [https://lists.archlinux.org/pipermail/arch-general/2013-October/034352.html][https://lists.archlinux.org/pipermail/arch-general/2017-February/043149.html]). The status of unofficial support is:<br />
<br />
{| class="wikitable"<br />
! Name !! Status !! Available at<br />
|-<br />
| SELinux enabled kernel || Implemented for {{pkg|linux}}, {{pkg|linux-zen}} and {{pkg|linux-hardened}} || Available in official repositories since [https://git.archlinux.org/svntogit/packages.git/commit/?id=c46609a4b0325c363455264844091b71de01eddc 4.18.8].<br />
|-<br />
| SELinux Userspace tools and libraries || Implemented in AUR: https://aur.archlinux.org/packages/?O=0&K=selinux || Work is done at https://github.com/archlinuxhardened/selinux<br />
|-<br />
| SELinux Policy || Work in progress, using [https://github.com/SELinuxProject/refpolicy Reference Policy] as upstream || Upstream: https://github.com/SELinuxProject/refpolicy (since release 20170805 the policy has integrated support for systemd and single-/usr/bin directory)<br />
|}<br />
<br />
Summary of changes in AUR as compared to official core packages:<br />
<br />
{| class="wikitable"<br />
! Name !! Status and comments<br />
|-<br />
| linux || Need following [[kernel parameters]] at boot: {{ic|1=selinux=1 security=selinux}}<br />
|-<br />
| linux-hardened || Need following [[kernel parameters]] at boot: {{ic|1=selinux=1 security=selinux}}<br />
|-<br />
| coreutils || Need a rebuild with {{ic|--with-selinux}} flag to link with libselinux<br />
|-<br />
| cronie || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| dbus || Need a rebuild with {{ic|--enable-libaudit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| findutils || Need a rebuild with libselinux installed to enable SELinux-specific options<br />
|-<br />
| iproute2 || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| logrotate || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| openssh || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| pam || Need a rebuild with {{ic|--enable-selinux}} flag for Linux-PAM ; Need a patch for pam_unix2, which only removes a function already implemented in a recent versions of libselinux<br />
|-<br />
| pambase || Configuration changes to add pam_selinux.so to {{ic|/etc/pam.d/system-login}}<br />
|-<br />
| psmisc || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| shadow || Need a rebuild with {{ic|--with-selinux}} flags<br />
|-<br />
| sudo || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| systemd || Need a rebuild with {{ic|--enable-audit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| util-linux || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
|}<br />
<br />
All of the other SELinux-related packages may be included without changes nor risks.<br />
<br />
==Concepts: Mandatory Access Controls==<br />
<br />
{{Note|This section is meant for beginners. If you know what SELinux does and how it works, feel free to skip ahead to the installation.}}<br />
<br />
Before you enable SELinux, it is worth understanding what it does. Simply and succinctly, SELinux enforces ''Mandatory Access Controls (MACs)'' on Linux. In contrast to SELinux, the traditional user/group/rwx permissions are a form of ''Discretionary Access Control (DAC)''. MACs are different from DACs because security policy and its execution are completely separated.<br />
<br />
An example would be the use of the ''sudo'' command. When DACs are enforced, sudo allows temporary privilege escalation to root, giving the process so spawned unrestricted systemwide access. However, when using MACs, if the security administrator deems the process to have access only to a certain set of files, then no matter what the kind of privilege escalation used, unless the security policy itself is changed, the process will remain constrained to simply that set of files. So if ''sudo'' is tried on a machine with SELinux running in order for a process to gain access to files its policy does not allow, it will fail.<br />
<br />
Another set of examples are the traditional (-rwxr-xr-x) type permissions given to files. When under DAC, these are user-modifiable. However, under MAC, a security administrator can choose to freeze the permissions of a certain file by which it would become impossible for any user to change these permissions until the policy regarding that file is changed.<br />
<br />
As you may imagine, this is particularly useful for processes which have the potential to be compromised, i.e. web servers and the like. If DACs are used, then there is a particularly good chance of havoc being wreaked by a compromised program which has access to privilege escalation.<br />
<br />
For further information, visit [[wikipedia:Mandatory access control]].<br />
<br />
==Installing SELinux==<br />
<br />
===Package description===<br />
<br />
All SELinux related packages belong to the ''selinux'' group in the AUR.<br />
<br />
====SELinux aware system utilities====<br />
<br />
;{{AUR|coreutils-selinux}}<br />
:Modified coreutils package compiled with SELinux support enabled. It replaces the {{pkg|coreutils}} package<br />
<br />
;{{AUR|cronie-selinux}}<br />
:Fedora fork of Vixie cron with SELinux enabled. It replaces the {{pkg|cronie}} package.<br />
<br />
;{{AUR|dbus-selinux}}<br />
:An SELinux aware version of [[D-Bus]]. It replaces the {{pkg|dbus}} package.<br />
<br />
;{{AUR|findutils-selinux}}<br />
:Patched findutils package compiled with SELinux support to make searching of files with specified security context possible. It replaces the {{pkg|findutils}} package.<br />
<br />
;{{AUR|iproute2-selinux}}<br />
:iproute2 package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|ss}}. It replaces the {{pkg|iproute2}} package.<br />
<br />
;{{AUR|logrotate-selinux}}<br />
:Logrotate package compiled with SELinux support. It replaces the {{pkg|logrotate}} package.<br />
<br />
;{{AUR|openssh-selinux}}<br />
:[[OpenSSH]] package compiled with SELinux support to set security context for user sessions. It replaces the {{pkg|openssh}} package.<br />
<br />
;{{AUR|pam-selinux}} and {{AUR|pambase-selinux}}<br />
:PAM package with pam_selinux.so. and the underlying base package. They replace the {{pkg|pam}} and {{pkg|pambase}} packages respectively.<br />
<br />
;{{AUR|psmisc-selinux}}<br />
:Psmisc package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|killall}}. It replaces the {{pkg|psmisc}} package.<br />
<br />
;{{AUR|shadow-selinux}}<br />
:Shadow package compiled with SELinux support; contains a modified {{ic|/etc/pam.d/login}} file to set correct security context for user after login. It replaces the {{pkg|shadow}} package.<br />
<br />
;{{AUR|sudo-selinux}}<br />
:Modified [[sudo]] package compiled with SELinux support which sets the security context correctly. It replaces the {{pkg|sudo}} package.<br />
<br />
;{{AUR|systemd-selinux}}<br />
:An SELinux aware version of [[Systemd]]. It replaces the {{pkg|systemd}} package.<br />
<br />
;{{AUR|util-linux-selinux}}<br />
:Modified util-linux package compiled with SELinux support enabled. It replaces the {{pkg|util-linux}} package.<br />
<br />
====SELinux userspace utilities====<br />
;{{AUR|checkpolicy}}<br />
:Tools to build SELinux policy<br />
<br />
;{{AUR|mcstrans}}<br />
:Daemon which is used by libselinux to translate MCS labels<br />
<br />
;{{AUR|libselinux}}<br />
:Library for security-aware applications. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsemanage}}<br />
:Library for policy management. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsepol}}<br />
:Library for binary policy manipulation.<br />
<br />
;{{AUR|policycoreutils}}<br />
:SELinux core utils such as newrole, setfiles, etc.<br />
<br />
;{{AUR|restorecond}}<br />
:Daemon which maintains the label of some files<br />
<br />
;{{AUR|secilc}}<br />
:Compiler for SELinux policies written in CIL (Common Intermediate Language)<br />
<br />
;{{AUR|selinux-dbus-config}}<br />
:DBus service which allows managing SELinux configuration<br />
<br />
;{{AUR|selinux-gui}}<br />
:SELinux GUI tools (system-config-selinux)<br />
<br />
;{{AUR|selinux-python}} and {{AUR|selinux-python2}}<br />
:SELinux python tools and libraries (semanage, sepolgen, sepolicy, etc.)<br />
<br />
;{{AUR|selinux-sandbox}}<br />
:Sandboxing tool for SELinux<br />
<br />
;{{AUR|semodule-utils}}<br />
:Tools to handle SELinux modules when building a policy<br />
<br />
====SELinux policy packages====<br />
<br />
;{{AUR|selinux-refpolicy-src}}<br />
:Reference policy sources<br />
<br />
;{{AUR|selinux-refpolicy-git}}<br />
:Reference policy git master (https://github.com/SELinuxProject/refpolicy) built with configuration specific for Arch Linux<br />
<br />
;{{AUR|selinux-refpolicy-arch}}<br />
:Precompiled modular Reference policy with headers and documentation but without sources. Development Arch Linux Refpolicy patches included, which fixes issues related to path labeling and systemd support. These patches are also sent to Reference Policy maintainers and their inclusion in {{AUR|selinux-refpolicy-arch}} is mainly a way to perform updates between Refpolicy releases.<br />
<br />
====Other SELinux tools====<br />
<br />
;{{AUR|setools}}<br />
:CLI and GUI tools to manage SELinux<br />
<br />
;{{AUR|selinux-alpm-hook}}<br />
:pacman hook to label files accordingly to SELinux policy when installing and updating packages<br />
<br />
=== Installation ===<br />
<br />
There are two methods to install the requisite SELinux packages.<br />
<br />
==== Via AUR ====<br />
<br />
* First, install SELinux userspace tools and libraries, in this order (because of the dependencies): {{AUR|libsepol}}, {{AUR|libselinux}}, {{AUR|secilc}}, {{AUR|checkpolicy}}, {{AUR|setools}}, {{AUR|libsemanage}}, {{AUR|semodule-utils}}, {{AUR|policycoreutils}}, {{AUR|selinux-python}} (which depends on {{AUR|python-ipy}}), {{AUR|mcstrans}} and {{AUR|restorecond}}.<br />
* Then install {{AUR|pambase-selinux}} and {{AUR|pam-selinux}} and make sure you can login again after the installation completed, because files in {{ic|/etc/pam.d/}} got removed and created when {{pkg|pambase}} got replaced with {{AUR|pambase-selinux}}.<br />
* Next you can recompile some core packages by installing: {{AUR|coreutils-selinux}}, {{AUR|findutils-selinux}}, {{AUR|iproute2-selinux}}, {{AUR|logrotate-selinux}}, {{AUR|openssh-selinux}}, {{AUR|psmisc-selinux}}, {{AUR|shadow-selinux}}, {{AUR|cronie-selinux}}<br />
* Next, backup your {{ic|/etc/sudoers}} file. Install {{AUR|sudo-selinux}} and restore your {{ic|/etc/sudoers}} (it is overridden when this package is installed as a replacement of {{pkg|sudo}}).<br />
* Next come util-linux and systemd. Because of a cyclic makedepends between these two packages which will not be fixed ({{bug|39767}}), you need to build the source package {{AUR|systemd-selinux}}, install {{AUR|systemd-libs-selinux}}, build and install {{AUR|util-linux-selinux}} (with {{AUR|libutil-linux-selinux}}) and rebuild and install {{AUR|systemd-selinux}}.<br />
* Next, install {{AUR|dbus-selinux}}.<br />
* Next, install {{AUR|selinux-alpm-hook}} in order to run restorecon every time pacman installs a package.<br />
<br />
After all these steps, you can install a SELinux kernel (like {{AUR|linux-selinux}}) and a policy (like {{AUR|selinux-refpolicy-arch}} or {{AUR|selinux-refpolicy-git}}).<br />
<br />
==== Using the GitHub repository ====<br />
<br />
All packages are maintained at https://github.com/archlinuxhardened/selinux . This repository also contains a script named {{ic|build_and_install_all.sh}} which builds and installs (or updates) all packages in the needed order. Here is an example of a way this script can be used in a user shell to install all packages (with downloading the GPG keys which are used to verify the source tarballs of the package):<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux<br />
./recv_gpg_keys.sh<br />
./build_and_install_all.sh<br />
<br />
Of course, it is possible to modify the content of {{ic|build_and_install_all.sh}} before running it, for example if you already have SELinux support in your kernel.<br />
<br />
===Changing boot loader configuration===<br />
<br />
If you have installed a new kernel, make sure that you update your bootloader accordingly to boot on it. Moreover you may need to add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to the kernel command line. More precisely, if the kernel configuration does not set {{ic|CONFIG_DEFAULT_SECURITY_SELINUX}}, {{ic|<nowiki>security=selinux</nowiki>}} is needed, and if it contains {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM=y</nowiki>}} {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0</nowiki>}}, {{ic|<nowiki>selinux=1</nowiki>}} is needed.<br />
<br />
====GRUB====<br />
<br />
Add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variable in {{ic|/etc/default/grub}}<br />
Run the following command:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
====Syslinux====<br />
<br />
Change your syslinux.cfg file by adding:<br />
<br />
{{hc|/boot/syslinux/syslinux.cfg|<nowiki>LABEL arch-selinux<br />
LINUX ../vmlinuz-linux-selinux<br />
APPEND root=/dev/sda2 ro security=selinux selinux=1<br />
INITRD ../initramfs-linux-selinux.img</nowiki>}}<br />
<br />
at the end. Change "linux-selinux" to whatever kernel you are using.<br />
<br />
====systemd-boot====<br />
<br />
Create a new loader entry, for example in {{ic|/boot/loader/entries/arch-selinux.conf}}:<br />
<br />
{{hc|/boot/loader/entries/arch-selinux.conf|2=<br />
title Arch Linux SELinux<br />
linux /vmlinuz-linux-selinux<br />
initrd /initramfs-linux-selinux.img<br />
options root=/dev/sda2 ro selinux=1 security=selinux<br />
}}<br />
<br />
===Checking PAM===<br />
<br />
A correctly set-up [[PAM]] is important to get the proper security context after login. Check for the presence of the following lines in {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{bc|# pam_selinux.so close should be the first session rule<br />
session required pam_selinux.so close}}<br />
<br />
{{bc|# pam_selinux.so open should only be followed by sessions to be executed in the user context<br />
session required pam_selinux.so open}}<br />
<br />
===Installing a policy===<br />
<br />
{{Warning|The reference policy as given by [https://github.com/SELinuxProject/refpolicy/wiki SELinuxProject] is not very good for Arch Linux, as before release 20170805 almost no file were labelled correctly. The major problems were:<br />
<br />
* {{ic|/lib}} and {{ic|/usr/lib}} were considered different (and also {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/bin}} and {{ic|/usr/sbin}}). This introduced some instability when applying labels to the whole system, as files in these folders might be seen with 2 (or 4) different labels. <br />
* systemd was not yet supported (C. PeBenito, main developer of the refpolicy, announced its willingness to work on it in its github repository in October 2014, http://oss.tresys.com/pipermail/refpolicy/2014-October/007430.html)<br />
<br />
Since refpolicy release 20170805 these two points have been addressed, but most people submitting patches to improve the policy use an other distribution (Debian, Gentoo, RHEL, etc.). Therefore the compatibility with Arch Linux packages is not perfect (for example the policy may not support the most recent features of a program). }}<br />
<br />
Policies are the mainstay of SELinux. They are what govern its behaviour. The only policy currently available in the AUR is the Reference Policy. In order to install it, you should use the source files, which may be got from the package {{AUR|selinux-refpolicy-src}} or by downloading the latest release on https://github.com/SELinuxProject/refpolicy/wiki/DownloadRelease#current-release. When using the AUR package, navigate to {{ic|/etc/selinux/refpolicy/src/policy}} and run the following commands:<br />
<br />
{{bc|# make bare<br />
# make conf<br />
# make install}}<br />
<br />
to install the reference policy as it is. Those who know how to write SELinux policies can tweak them to their heart's content before running the commands written above. The command takes a while to do its job and taxes one core of your system completely, so do not worry. Just sit back and let the command run for as long as it takes.<br />
<br />
To load the reference policy run:<br />
{{bc|# make load}}<br />
<br />
Then, make the file {{ic|/etc/selinux/config}} with the following contents (Only works if you used the defaults as mentioned above. If you decided to change the name of the policy, you need to tweak the file):<br />
<br />
{{hc|/etc/selinux/config|<nowiki># This file controls the state of SELinux on the system.<br />
# SELINUX= can take one of these three values:<br />
# enforcing - SELinux security policy is enforced.<br />
# Set this value once you know for sure that SELinux is configured the way you like it and that your system is ready for deployment<br />
# permissive - SELinux prints warnings instead of enforcing.<br />
# Use this to customise your SELinux policies and booleans prior to deployment. Recommended during policy development.<br />
# disabled - No SELinux policy is loaded.<br />
# This is not a recommended setting, for it may cause problems with file labelling<br />
SELINUX=permissive<br />
# SELINUXTYPE= takes the name of SELinux policy to<br />
# be used. Current options are:<br />
# refpolicy (vanilla reference policy)<br />
# <custompolicy> - Substitute <custompolicy> with the name of any custom policy you choose to load<br />
SELINUXTYPE=refpolicy</nowiki>}}<br />
<br />
Now, you may reboot. After rebooting, run:<br />
<br />
# restorecon -r /<br />
<br />
to label your filesystem.<br />
<br />
Now, make a file {{ic|requiredmod.te}} with the contents:<br />
<br />
{{hc|requiredmod.te|<nowiki>module requiredmod 1.0;<br />
<br />
require {<br />
type devpts_t;<br />
type kernel_t;<br />
type device_t;<br />
type var_run_t;<br />
type udev_t;<br />
type hugetlbfs_t;<br />
type udev_tbl_t;<br />
type tmpfs_t;<br />
class sock_file write;<br />
class unix_stream_socket { read write ioctl };<br />
class capability2 block_suspend;<br />
class dir { write add_name };<br />
class filesystem associate;<br />
}<br />
<br />
#============= devpts_t ==============<br />
allow devpts_t device_t:filesystem associate;<br />
<br />
#============= hugetlbfs_t ==============<br />
allow hugetlbfs_t device_t:filesystem associate;<br />
<br />
#============= kernel_t ==============<br />
allow kernel_t self:capability2 block_suspend;<br />
<br />
#============= tmpfs_t ==============<br />
allow tmpfs_t device_t:filesystem associate;<br />
<br />
#============= udev_t ==============<br />
allow udev_t kernel_t:unix_stream_socket { read write ioctl };<br />
allow udev_t udev_tbl_t:dir { write add_name };<br />
allow udev_t var_run_t:sock_file write;</nowiki>}}<br />
<br />
and run the following commands:<br />
<br />
{{bc|<nowiki># checkmodule -m -o requiredmod.mod requiredmod.te<br />
# semodule_package -o requiredmod.pp -m requiredmod.mod<br />
# semodule -i requiredmod.pp</nowiki>}}<br />
<br />
This is required to remove a few messages from {{ic|/var/log/audit/audit.log}} which are a nuisance to deal with in the reference policy. This is an ugly hack and it should be made very clear that the policy so installed simply patches the reference policy in order to hide the effects of incorrect labelling.<br />
<br />
===Testing in a Vagrant virtual machine===<br />
<br />
It is possible to use [[Vagrant]] to provision a virtual Arch Linux machine with SELinux configured. This is a convenient way to test an Arch Linux system running SELinux without modifying a current system. Here are commands which can be used to achieve this:<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux/_vagrant<br />
vagrant up<br />
vagrant ssh<br />
<br />
==Post-installation steps==<br />
<br />
You can check that SELinux is working with {{ic|sestatus}}. You should get something like:<br />
<br />
{{bc|<nowiki>SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
SELinux root directory: /etc/selinux<br />
Loaded policy name: refpolicy<br />
Current mode: permissive<br />
Mode from config file: permissive<br />
Policy MLS status: disabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 28</nowiki>}}<br />
<br />
To maintain correct context, you can use ''restorecond'':<br />
<br />
# systemctl enable restorecond<br />
<br />
To switch to enforcing mode without rebooting, you can use:<br />
<br />
# echo 1 > /sys/fs/selinux/enforce<br />
<br />
===Swapfiles===<br />
<br />
If you have a swap file instead of a swap partition, issue the following commands in order to set the appropriate security context:<br />
<br />
{{bc|# semanage fcontext -a -t swapfile_t "/path/to/swapfile"<br />
# restorecon /path/to/swapfile}}<br />
<br />
==Working with SELinux==<br />
<br />
SELinux defines security using a different mechanism than traditional Unix access controls. The best way to understand it is by example. For example, the SELinux security context of the apache homepage looks like the following:<br />
<br />
$ls -lZ /var/www/html/index.html<br />
-rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html<br />
<br />
The first three and the last columns should be familiar to any (Arch) Linux user. The fourth column is new and has the format:<br />
<br />
user:role:type[:level]<br />
<br />
To explain:<br />
#'''User:''' The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br />
#'''Role:''' The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br />
#'''Type:''' When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br />
#'''Level:''' This optional field can also be know as a range and is only present if the policy supports MCS or MLS.<br />
<br />
This is important in case you wish to understand how to build your own policies, for these are the basic building blocks of SELinux. However, for most purposes, there is no need to, for the reference policy is sufficiently mature. However, if you are a power user or someone with very specific needs, then it might be ideal for you to learn how to make your own SELinux policies.<br />
<br />
[http://www.fosteringlinux.com/tag/selinux/ This] is a great series of articles for someone seeking to understand how to work with SELinux.<br />
<br />
==Troubleshooting==<br />
<br />
The place to look for SELinux errors is the [[systemd journal]]. In order to see SELinux messages related to the label {{ic|system_u:system_r:policykit_t:s0}} (for example), you would need to run:<br />
<br />
# journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0<br />
<br />
===Useful tools===<br />
<br />
There are some tools/commands that can greatly help with SELinux. <br />
<br />
;restorecon: Restores the context of a file/directory (or recursively with {{ic|-R}}) based on any policy rules <br />
;chcon: Change the context on a specific file<br />
<br />
===Reporting issues===<br />
<br />
Please report issues on GitHub: https://github.com/archlinuxhardened/selinux/issues<br />
<br />
==See also==<br />
* [[wikipedia:Security-Enhanced_Linux|Security Enhanced Linux]]<br />
* [https://wiki.gentoo.org/wiki/SELinux Gentoo SELinux Handbook]<br />
* [https://fedoraproject.org/wiki/SELinux Fedora Project's SELinux Wiki]<br />
* [https://www.nsa.gov/what-we-do/research/selinux/ NSA's Official SELinux Homepage]<br />
* [https://github.com/SELinuxProject SELinux Project Homepage]<br />
** [https://github.com/SELinuxProject/refpolicy/wiki Reference Policy Homepage]<br />
** [https://github.com/SELinuxProject/setools/wiki SETools Homepage]<br />
* [https://web.archive.org/web/20140816115906/http://jamesthebard.net/archlinux-selinux-and-you-a-trip-down-the-rabbit-hole/ ArchLinux, SELinux and You (archived)]</div>Jussihihttps://wiki.archlinux.org/index.php?title=Talk:Archiso&diff=556591Talk:Archiso2018-11-22T15:59:15Z<p>Jussihi: There was a stupid simple question about how to enlarge the ISO if "too much" space is used. The ISO grows as needed, use forum for stupid simple questions like this.</p>
<hr />
<div>==Sourceforce error for edk2 files==<br />
<br />
build.sh contains the following two lines:<br />
<br />
<code>curl -o ${work_dir}/iso/EFI/shellx64_v2.efi https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi<br />
<br/>curl -o ${work_dir}/iso/EFI/shellx64_v1.efi https://svn.code.sf.net/p/edk2/code/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi</code><br />
<br />
These lines failed with the error: ''curl: (7) Failed to connect to svn.code.sf.net port 443: Connection refused''<br/><br />
As a workaround, I used those same files from the GitHub page of the TianoCore Project:<br />
<br />
<code>curl -o ${work_dir}/iso/EFI/shellx64_v2.efi https://github.com/tianocore/edk2/blob/master/EdkShellBinPkg/MinimumShell/X64/Shell.efi?raw=true<br/><br />
curl -o ${work_dir}/iso/EFI/shellx64_v1.efi https://github.com/tianocore/edk2/blob/master/EdkShellBinPkg/FullShell/Arm/Shell_Full.efi?raw=true</code><br />
<br />
Not sure if this is a temporary problem or those URLs need to be replaced permanently.<br />
--[[User:TcShadowWalker|TcShadowWalker]] ([[User talk:TcShadowWalker|talk]]) 19:48, 16 July 2015 (UTC)<br />
<br />
==Archiso doesn't work on non stock kernel==<br />
<br />
I've been having on and off issues when building ISOs with archiso and the other day when I was working on one I did a pacman -Syu before working but didn't reboot. I was running on the stock kernel at that point because the linux-ck kernel had not updated yet. My ISO built fine. Later that day I rebooted and was now running on the updated linux-ck kernel and suddenly the build process would simply die without any errors, even with the -v option. Right after installing all the custom packages, a dd output appears and then a mkfs.vfat version message appears and that's where it dies. Rebooting back to the stock arch kernel fixed the issue. I'm guessing it has something to do with hardcoded names or something like that in the build scripts.<br />
<br />
Is this normal behaviour? I don't mind using the stock kernel on the ISOs I build but I figured I'd at least be able to build them on a different one.<br />
<br />
On that note, is it possible to use a kernel other than the stock one within the ISOs we build? <br />
[[User:Biltong|Biltong]] ([[User talk:Biltong|talk]]) Sun May 6 2012, 21:47 SAST<br />
<br />
== Sidenote: ==<br />
<br />
Re-initializing pacman can be important, though I'm not sure. [[Pacman-key#Initializing_the_keyring]]<br />
<br />
Consider trying out -Archboot- GUI for installation: [[FAQ#Q.29_Arch_needs_an_installer._Maybe_a_GUI_installer]]<br />
<br />
{{Unsigned|01:40, 28 March 2013|Ubunchu}}<br />
<br />
== Estimating size? Starting over? ==<br />
<br />
How do you best estimate the size?<br />
<br />
How do you start over? Suppose just take `etc/`, delete the `releng/` directory recopy, put stuff back. [[User:Jasper1984|Jasper1984]] ([[User talk:Jasper1984|talk]]) 13:46, 1 July 2013 (UTC)<br />
<br />
:Best way to start over is delete releng/{work,out} it keeps cached packages, and there is no need to do every step from the beginning. {{Unsigned|14:08, 5 October 2013|Jqvillanova}}<br />
<br />
== Encryption ==<br />
<br />
<br />
* with «cryptsetup», encrypt the file «airootfs.sfs» built with «mkarchiso» :<br />
<br />
# cd /path/to/buildir/<br />
# cd ./work/iso/arch/x86_64/<br />
# cryptsetup --verify-passphrase plainOpen ./airootfs.sfs encrypt<br />
# dd < ./airootfs.sfs > /dev/mapper/encrypt<br />
# sync<br />
# cryptsetup plainClose encrypt<br />
# md5sum ./airootfs.sfs > ./airootfs.md5<br />
# cd -<br />
<br />
''(note that you can't decrypt the encrypted file «airootfs.sfs» in the same «dd» way, instead use {{ic|1=dd of=./airootfs.sfs conv=nocreat,notrunc < /dev/mapper/encrypt}})''<br />
<br />
* add the hook «encrypt» in «mkinitcpio.conf» :<br />
<br />
# grep HOOKS ./work/airootfs/etc/mkinitcpio.conf<br />
HOOKS="... encrypt"<br />
<br />
<br />
* insert these lines in «archiso» hook :<br />
<br />
--- a/work/airootfs/usr/lib/initcpio/hooks/archiso<br />
+++ b/work/airootfs/usr/lib/initcpio/hooks/archiso<br />
@@ -65,6 +65,10 @@<br />
fi<br />
sfs_dev=$(losetup --find --show --read-only "${img}")<br />
echo ${sfs_dev} >> /run/archiso/used_block_devices<br />
+ msg ":: Mapping encrypted squashfs..."<br />
+ local map="${sfs_dev##*/}.map"<br />
+ cryptsetup plainOpen "${sfs_dev}" "${map}"<br />
+ sfs_dev="/dev/mapper/${map}"<br />
_mnt_dev "${sfs_dev}" "${mnt}" "-r" "defaults"<br />
}<br />
<br />
<br />
* rebuild initramfs and iso with «mkarchiso» and test :<br />
<br />
# mkarchiso -r "mkinitcpio -p linux" run<br />
# mkarchiso iso encrypted.iso<br />
# qemu ... ./out/encrypted.iso<br />
<br />
<br />
[[User:Lacsap|Lacsap]] ([[User talk:Lacsap|talk]]) 21:51, 20 Feb 2016 (UTC)<br />
<br />
== Rebuilding the iso after removing the lock files is not enough ==<br />
<br />
The wiki states that to rebuild the iso, you have to remove lock files in the work directory<br />
<br />
However, this is not enough, because the script stops after reaching "adduser" command with "user exists" error [[User:Hadiyazdi|Hadiyazdi]] ([[User talk:Hadiyazdi|talk]]) 13:50, 11 March 2015 (UTC)<br />
<br />
== Copying file tha neither go in /skel/ or /etc/ ==<br />
<br />
It is unclear whether it is possible and how to prepare folder in some other directory of the hierarchy. E.g. if one wanted to prepare a custom xinitrc file, should one run<br />
<br />
# mkdir /etc/X11/xinit/xinitrc<br />
# cp /path/to/customxinitrc/xinitrc /etc/X11/xinit/xinitrc<br />
<br />
or whether one should put instead a dedicated line in one of the building script.<br />
<br />
I am not yet qualified enough to do this, but it is not a request for personal help, but rather a issue concerning a relevant (imo) point in the page.<br />
<br />
[[User:Navi se|Navi se]] ([[User talk:Navi se|talk]]) 12:37, 6 January 2016 (UTC)<br />
<br />
== Style|typo tag discussion for id/useradd check/command ==<br />
<br />
The following was tagged with "{{[[Template:Style|Style]]|typo?}}":<br />
<br />
! id arch && useradd -m -p "" -g users -G "adm,audio,floppy,log,network,rfkill,scanner,storage,optical,power,wheel" -s /usr/bin/zsh arch<br />
<br />
I tried the command and also variations. They work, so may I remove the template/tag? Or, did it refer to something else? Or, maybe explain why {{ic|!}} and {{ic|&&}} are used? [[User:Zeniff|Zeniff]] ([[User talk:Zeniff|talk]]) 02:39, 30 October 2016 (UTC)</div>Jussihihttps://wiki.archlinux.org/index.php?title=Archiso&diff=539238Archiso2018-09-01T16:56:37Z<p>Jussihi: /* UEFI SecureBoot */ fix typo</p>
<hr />
<div>[[Category:Live Arch systems]]<br />
[[Category:Getting and installing Arch]]<br />
[[Category:Arch projects]]<br />
[[ar:Archiso]]<br />
[[el:Archiso]]<br />
[[es:Archiso]]<br />
[[fr:Archiso]]<br />
[[it:Archiso]]<br />
[[ja:Archiso]]<br />
[[nl:Archiso]]<br />
[[ru:Archiso]]<br />
[[sk:Archiso]]<br />
[[zh-hans:Archiso]]<br />
{{Related articles start}}<br />
{{Related|Remastering the Install ISO}}<br />
{{Related|Archiso as pxe server}}<br />
{{Related|Archboot}}<br />
{{Related articles end}}<br />
'''Archiso''' is a small set of bash scripts capable of building fully functional Arch Linux live CD/DVD/USB images. It is the same tool used to generate the official images, but since it is a very generic tool, it can be used to generate anything from rescue systems, install disks, to special interest live CD/DVD/USB systems, and who knows what else. Simply put, if it involves Arch on a shiny coaster, it can do it. The heart and soul of Archiso is ''mkarchiso''. All of its options are documented in its usage output, so its direct usage will not be covered here. Instead, this wiki article will act as a guide for rolling your own live media in no time!<br />
<br />
== Setup ==<br />
<br />
{{Note|It is recommended to act as root in all the following steps. If not, it is very likely to have problems with false permissions later.}}<br />
Before you begin, [[install]] the {{Pkg|archiso}} or {{AUR|archiso-git}} package.<br />
<br />
Archiso comes with two "profiles": ''releng'' and ''baseline''.<br />
<br />
* If you wish to create a fully customized live version of Arch Linux, pre-installed with all your favorite programs and configurations, use ''releng''.<br />
* If you just want to create the most basic live medium, with no pre-installed packages and a minimalistic configuration, use ''baseline''.<br />
<br />
Now, copy the profile of your choice to a directory (''archlive'' in the example below) where you can make adjustments and build it. Execute the following, replacing {{ic|'''profile'''}} with either {{ic|releng}} or {{ic|baseline}}.<br />
<br />
# cp -r /usr/share/archiso/configs/'''profile'''/ ''archlive''<br />
<br />
* If you are using the {{ic|releng}} profile to make a fully customized image, then you can proceed onto [[#Configure the live medium]].<br />
* If you are using the {{ic|baseline}} profile to create a bare image, then you will not be needing to do any customization and can proceed onto [[#Build the ISO]].<br />
<br />
== Configure the live medium ==<br />
<br />
This section details configuring the image you will be creating, allowing you to define the packages and configurations you want your live image to contain.<br />
<br />
Inside the {{ic|''archlive''}} directory created in [[#Setup]] there are a number of files and directories; we are only concerned with a few of these, mainly: <br />
* {{ic|packages.x86_64}} - this is where you list, line by line, the packages you want to have installed, and<br />
* the {{ic|airootfs}} directory - this directory acts as an overlay and it is where you make all the customizations.<br />
<br />
Generally, every administrative task that you would normally do after a fresh install except for package installation can be scripted into {{ic|''archlive''/airootfs/root/customize_airootfs.sh}}. It has to be written from the perspective of the new environment, so {{ic|/}} in the script means the root of the live-iso which is to be created.<br />
<br />
=== Installing packages ===<br />
<br />
[[Edit]] the lists of packages in {{ic|packages.x86_64}} to indicate which packages are to be installed on the live medium.<br />
<br />
{{Note|If you want to use a [[window manager]] in the Live CD then you must add the necessary and correct [[video drivers]], or the WM may freeze on loading.}}<br />
<br />
==== Custom local repository ====<br />
<br />
{{Merge|Pacman tips#Custom local repository|Move the general information (e.g. repo tree) into the main article.}}<br />
<br />
For the purpose of preparing custom packages or packages from [[AUR]]/[[ABS]], you could also [[custom local repository|create a custom local repository]]. If you are looking to support multiple architectures then precautions should be taken to prevent errors from occurring. Each architecture should have its own directory tree:<br />
<br />
{{hc|$ tree ~/customrepo/ {{!}} sed "s/$(uname -m)/<arch>/g"|<br />
/home/archie/customrepo/<br />
└── <arch><br />
├── customrepo.db -> customrepo.db.tar.xz<br />
├── customrepo.db.tar.xz<br />
├── customrepo.files -> customrepo.files.tar.xz<br />
├── customrepo.files.tar.xz<br />
└── personal-website-git-b99cce0-1-<arch>.pkg.tar.xz<br />
<br />
1 directory, 5 files<br />
}}<br />
You can then add your repository by putting the following into {{ic|~/archlive/pacman.conf}}, above the other repository entries (for top priority):<br />
<br />
{{hc|~/archlive/pacman.conf|...<br />
# custom repository<br />
[customrepo]<br />
SigLevel <nowiki>=</nowiki> Optional TrustAll<br />
Server <nowiki>=</nowiki> file:///home/'''user'''/customrepo/$arch<br />
...}}<br />
<br />
The ''repo-add'' executable checks if the package is appropriate. If this is not the case you will be running into error messages similar to this:<br />
<br />
==> ERROR: '/home/archie/customrepo/<arch>/foo-<arch>.pkg.tar.xz' does not have a valid database archive extension.<br />
<br />
==== Preventing installation of packages belonging to base group ====<br />
<br />
By default, {{ic|/usr/bin/mkarchiso}}, a script which is used by {{ic|~/archlive/build.sh}}, calls one of the {{Pkg|arch-install-scripts}} named {{ic|pacstrap}} without the {{ic|-i}} flag, which causes [[Pacman]] to not wait for user input during the installation process.<br />
<br />
When blacklisting base group packages by adding them to the {{ic|IgnorePkg}} line in {{ic|~/archlive/pacman.conf}}, [[Pacman]] asks if they still should be installed, which means they will when user input is bypassed. To get rid of these packages there are several options:<br />
<br />
* '''Dirty''': Add the {{ic|-i}} flag to each line calling {{ic|pacstrap}} in {{ic|/usr/bin/mkarchiso}}.<br />
<br />
* '''Clean''': Create a copy of {{ic|/usr/bin/mkarchiso}} in which you add the flag and adapt {{ic|~/archlive/build.sh}} so that it calls the modified version of the mkarchiso script.<br />
<br />
* '''Advanced''': Create a function for {{ic|~/archlive/build.sh}} which explicitly removes the packages after the base installation. This would leave you the comfort of not having to type enter so much during the installation process.<br />
<br />
==== Installing packages from multilib ====<br />
<br />
To install packages from the [[multilib]] repository simply uncomment the repository in {{ic|~/archlive/pacman.conf}}:<br />
<br />
{{hc|pacman.conf|2=<br />
[multilib]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
}}<br />
<br />
=== Adding files to image ===<br />
<br />
{{Note|You must be root to do this, do not change the ownership of any of the files you copy over, '''everything''' within the airootfs directory must be root owned. Proper ownerships will be sorted out shortly.}}<br />
<br />
The airootfs directory acts as an overlay, think of it as root directory '/' on your current system, so any files you place within this directory will be copied over on boot-up.<br />
<br />
So if you have a set of iptables scripts on your current system you want to be used on you live image, copy them over as such:<br />
# cp -r /etc/iptables ~/archlive/airootfs/etc<br />
<br />
Placing files in the users home directory is a little different. Do not place them within {{ic|airootfs/home}}, but instead create a skel directory within {{ic|airootfs/}} and place them there. We will then add the relevant commands to the {{ic|customize_airootfs.sh}} which we are going to use to copy them over on boot and sort out the permissions.<br />
<br />
First, create the skel directory:<br />
# mkdir ~/archlive/airootfs/etc/skel<br />
<br />
Now copy the 'home' files to the skel directory, e.g for {{ic|.bashrc}}:<br />
# cp ~/.bashrc ~/archlive/airootfs/etc/skel/<br />
<br />
When {{ic|~/archlive/airootfs/root/customize_airootfs.sh}} is executed and a new user is created, the files from the skel directory will automatically be copied over to the new home folder, permissions set right.<br />
<br />
Similarly, some care is required for special configuration files that reside somewhere down the hierarchy. As an example the {{ic|/etc/X11/xinit/xinitrc}} configuration file resides on a path that might be overwritten by installing a package. To place the configuration file one should put the custom {{ic|xinitrc}} in {{ic|~/archlive/airootfs/etc/skel/}} and then modify {{ic|customize_airootfs.sh}} to move it appropriately.<br />
<br />
=== Boot Loader ===<br />
<br />
The default file should work fine, so you should not need to touch it.<br />
<br />
Due to the modular nature of isolinux, you are able to use lots of addons since all *.c32 files are copied and available to you. Take a look at the [http://syslinux.zytor.com/wiki/index.php/SYSLINUX official syslinux site] and the [https://projects.archlinux.org/archiso.git/tree/configs/syslinux-iso/boot-files archiso git repo]. Using said addons, it is possible to make visually attractive and complex menus. See [http://syslinux.zytor.com/wiki/index.php/Comboot/menu.c32 here].<br />
<br />
==== UEFI Secure Boot ====<br />
<br />
If you want to make your Archiso bootable on a UEFI Secure Boot enabled environment, you must use a signed bootloader. You can either follow the instructions on [[Secure Boot#Using a signed boot loader]] or you can use a bootloader of another distro with a old enough presigned bootloader, for example [http://releases.ubuntu.com/16.04/ Ubuntu 16.04]. If you choose to use the presigned EFI bootloader from Ubuntu, you first need to acquire the {{ic|/EFI/BOOT/}} and {{ic|/boot/}} folders from the Ubuntu ISO image. Then you need to edit the functions {{ic|make_efi()}} and {{ic|make_efiboot()}} in {{ic|~/archlive/build.sh}} to install the Ubuntu's GRUB bootloader instead of installing systemd bootloader. You should also edit the {{ic|/boot/grub/grub.cfg}} so that GRUB tries to boot your Archiso instead of Ubuntu.<br />
<br />
=== Login manager ===<br />
<br />
Starting X at boot is done by enabling your login manager's [[systemd]] service. If you know which .service file needs a softlink: Great. If not, you can easily find out in case you are using the same program on the system you build your iso on. Just use:<br />
<br />
$ ls -l /etc/systemd/system/display-manager.service<br />
<br />
Now create the same softlink in {{ic|~/archlive/airootfs/etc/systemd/system}}. For LXDM:<br />
<br />
# ln -s /usr/lib/systemd/system/lxdm.service ~/archlive/airootfs/etc/systemd/system/display-manager.service<br />
<br />
This will enable LXDM at system start on your live system.<br />
<br />
Alternatively you can just enable the service in {{ic|airootfs/root/customize_airootfs.sh}} along with other services that are enabled there.<br />
<br />
If you want the graphical environment to actually start automatically during boot make sure to edit {{ic|airootfs/root/customize_airootfs.sh}} and replace <br />
<br />
systemctl set-default multi-user.target<br />
with<br />
systemctl set-default graphical.target<br />
<br />
=== Changing Automatic Login ===<br />
<br />
The configuration for getty's automatic login is located under {{ic|airootfs/etc/systemd/system/getty@tty1.service.d/autologin.conf}}.<br />
<br />
You can modify this file to change the auto login user:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=-/sbin/agetty --autologin '''isouser''' --noclear %I 38400 linux<br />
<br />
Or remove it altogether to disable auto login.<br />
<br />
== Build the ISO ==<br />
<br />
Now you are ready to turn your files into the .iso which you can then burn to CD or USB:<br />
<br />
First create the {{ic|out/}} directory (optional, build.sh will create it if nonexist),<br />
<br />
# mkdir ~/archlive/out/<br />
<br />
then inside {{ic|~/archlive}}, execute:<br />
<br />
# ./build.sh -v<br />
<br />
The script will now download and install the packages you specified to {{ic|work/*/airootfs}}, create the kernel and init images, apply your customizations and finally build the iso into {{ic|out/}}.<br />
<br />
=== Rebuild the ISO ===<br />
<br />
Rebuilding the iso after modifications is not officially supported. However, it is easily possible by applying two steps. First you have to remove lock files in the work directory:<br />
<br />
# rm -v work/build.make_*<br />
<br />
Furthermore it is required to edit the script {{ic|airootfs/root/customize_airootfs.sh}}, and add an {{ic|id}} command in the beginning of the {{ic|useradd}} line as shown here. Otherwise the rebuild stops at this point because the user that is to be added already exists {{Bug|41865}}.<br />
<br />
{{Style|typo?}}<br />
<br />
! id arch && useradd -m -p "" -g users -G "adm,audio,floppy,log,network,rfkill,scanner,storage,optical,power,wheel" -s /usr/bin/zsh arch<br />
<br />
Also remove persistent data such as created users or symlinks such as {{ic|/etc/sudoers}}.<br />
<br />
{{Expansion|Report more data that needs to be removed or reset.}}<br />
<br />
Rebuilds can be sped up slightly by editing the pacstrap script (located at /bin/pacstrap) and changing the following at line 361:<br />
<br />
Before:<br />
<br />
if ! pacman -r "$newroot" -Sy "${pacman_args[@]}"; then<br />
<br />
After:<br />
<br />
if ! pacman -r "$newroot" -Sy --needed "${pacman_args[@]}"; then<br />
<br />
This increases the speed of the initial bootstrap, since it does not have to download and install any of the base packages that are already installed.<br />
<br />
== Using the ISO ==<br />
<br />
See the [[:Category:Getting and installing Arch#Installation methods]] section for various options.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Installation without Internet access ===<br />
<br />
{{Move|Installation without Internet access|seems like this could stand alone}}<br />
{{Accuracy|Instead of copying the files from the archiso, the "bootstrap" images available on the Arch mirrors can be extracted directly to the target disk. You will get a minimal system without the need to deal with the archiso modifications.}}<br />
<br />
If you wish to install the archiso (e.g. [https://www.archlinux.org/download/ the official monthly release]) as it is without an Internet connection, or, if you do not want to download the packages you want again:<br />
<br />
First, follow the [[Installation guide]], skipping the [[Installation guide#Connect to the Internet]] section, until the [[Installation guide#Install the base packages]] step.<br />
<br />
==== Install the archiso to the new root ====<br />
Instead of installing the packages with {{ic|pacstrap}} (which would try to download from the remote repositories), copy ''everything'' in the live environment to the new root:<br />
# cp -ax / /mnt<br />
{{Note|The option ({{ic|-x}}) excludes some special directories, as they should not be copied to the new root.}}<br />
Then, copy the kernel image to the new root, in order to keep the integrity of the new system:<br />
# cp -vaT /run/archiso/bootmnt/arch/boot/$(uname -m)/vmlinuz /mnt/boot/vmlinuz-linux<br />
<br />
After that, generate a fstab as described in [[Installation guide#Fstab]].<br />
<br />
==== Chroot and configure the base system ====<br />
Next, chroot into your newly installed system:<br />
# arch-chroot /mnt /bin/bash<br />
<br />
{{Note|Before performing the other [[Installation guide#Configure the system]] steps (e.g. locale, keymap, etc.), it is necessary to get rid of the trace of the Live environment (in other words, the customization of archiso which does not fit a non-Live environment).}}<br />
<br />
===== Restore the configuration of journald =====<br />
[https://projects.archlinux.org/archiso.git/tree/configs/releng/airootfs/root/customize_airootfs.sh#n19 This customization of archiso] will lead to storing the system journal in RAM, it means that the journal will not be available after reboot:<br />
# sed -i 's/Storage=volatile/#Storage=auto/' /etc/systemd/journald.conf<br />
<br />
===== Remove special udev rule =====<br />
[https://projects.archlinux.org/archiso.git/tree/configs/releng/airootfs/etc/udev/rules.d/81-dhcpcd.rules This rule of udev] starts the dhcpcd automatically if there are any wired network interfaces.<br />
<br />
# rm /etc/udev/rules.d/81-dhcpcd.rules<br />
<br />
===== Disable and remove the services created by archiso =====<br />
Some service files are created for the Live environment, please disable the services and remove the file as they are unnecessary for the new system:<br />
# systemctl disable pacman-init.service choose-mirror.service<br />
# rm -r /etc/systemd/system/{choose-mirror.service,pacman-init.service,etc-pacman.d-gnupg.mount,getty@tty1.service.d}<br />
# rm /etc/systemd/scripts/choose-mirror<br />
<br />
===== Remove special scripts of the Live environment =====<br />
There are some scripts installed in the live system by archiso scripts, which are unnecessary for the new system:<br />
# rm /etc/systemd/system/getty@tty1.service.d/autologin.conf<br />
# rm /root/{.automated_script.sh,.zlogin}<br />
# rm /etc/mkinitcpio-archiso.conf<br />
# rm -r /etc/initcpio<br />
<br />
===== Importing archlinux keys =====<br />
<br />
In order to use the official repositories, we need to import the archlinux master keys ([[pacman/Package signing#Initializing the keyring]]). This step is usually done by pacstrap but can be achieved with<br />
<br />
# pacman-key --init<br />
# pacman-key --populate archlinux<br />
<br />
{{Note| Keyboard or mouse activity is needed to generate entropy and speed-up the first step.}}<br />
<br />
===== Configure the system =====<br />
<br />
Now you can follow the skipped steps of the [[Installation guide#Configure the system]] section (setting a locale, timezone, hostname, etc.) and finish the installation by creating an initial ramdisk as described in [[Installation guide#Initramfs]].<br />
<br />
===== Enable graphical login (optional) =====<br />
<br />
If using a display manager like GDM, you may want to change the systemd default target from multi-user.target to one that allows graphical login.<br />
# systemctl disable multi-user.target<br />
# systemctl enable graphical.target<br />
<br />
== See also ==<br />
=== Documentation and tutorials ===<br />
* [https://projects.archlinux.org/archiso.git Archiso project page]<br />
* [https://projects.archlinux.org/archiso.git/tree/docs Official documentation]<br />
<br />
=== Example customization template ===<br />
* [http://easy.open.and.free.fr/didjix/ A live DJ distribution powered by ArchLinux and built with Archiso]<br />
<br />
=== Creating a offline installation ISO ===<br />
* [[Archiso offline]]</div>Jussihihttps://wiki.archlinux.org/index.php?title=Archiso&diff=539236Archiso2018-09-01T16:54:11Z<p>Jussihi: Added a brief explanation about UEFI Secure Boot under the bootloader secrion, and a couple workarounds for it.</p>
<hr />
<div>[[Category:Live Arch systems]]<br />
[[Category:Getting and installing Arch]]<br />
[[Category:Arch projects]]<br />
[[ar:Archiso]]<br />
[[el:Archiso]]<br />
[[es:Archiso]]<br />
[[fr:Archiso]]<br />
[[it:Archiso]]<br />
[[ja:Archiso]]<br />
[[nl:Archiso]]<br />
[[ru:Archiso]]<br />
[[sk:Archiso]]<br />
[[zh-hans:Archiso]]<br />
{{Related articles start}}<br />
{{Related|Remastering the Install ISO}}<br />
{{Related|Archiso as pxe server}}<br />
{{Related|Archboot}}<br />
{{Related articles end}}<br />
'''Archiso''' is a small set of bash scripts capable of building fully functional Arch Linux live CD/DVD/USB images. It is the same tool used to generate the official images, but since it is a very generic tool, it can be used to generate anything from rescue systems, install disks, to special interest live CD/DVD/USB systems, and who knows what else. Simply put, if it involves Arch on a shiny coaster, it can do it. The heart and soul of Archiso is ''mkarchiso''. All of its options are documented in its usage output, so its direct usage will not be covered here. Instead, this wiki article will act as a guide for rolling your own live media in no time!<br />
<br />
== Setup ==<br />
<br />
{{Note|It is recommended to act as root in all the following steps. If not, it is very likely to have problems with false permissions later.}}<br />
Before you begin, [[install]] the {{Pkg|archiso}} or {{AUR|archiso-git}} package.<br />
<br />
Archiso comes with two "profiles": ''releng'' and ''baseline''.<br />
<br />
* If you wish to create a fully customized live version of Arch Linux, pre-installed with all your favorite programs and configurations, use ''releng''.<br />
* If you just want to create the most basic live medium, with no pre-installed packages and a minimalistic configuration, use ''baseline''.<br />
<br />
Now, copy the profile of your choice to a directory (''archlive'' in the example below) where you can make adjustments and build it. Execute the following, replacing {{ic|'''profile'''}} with either {{ic|releng}} or {{ic|baseline}}.<br />
<br />
# cp -r /usr/share/archiso/configs/'''profile'''/ ''archlive''<br />
<br />
* If you are using the {{ic|releng}} profile to make a fully customized image, then you can proceed onto [[#Configure the live medium]].<br />
* If you are using the {{ic|baseline}} profile to create a bare image, then you will not be needing to do any customization and can proceed onto [[#Build the ISO]].<br />
<br />
== Configure the live medium ==<br />
<br />
This section details configuring the image you will be creating, allowing you to define the packages and configurations you want your live image to contain.<br />
<br />
Inside the {{ic|''archlive''}} directory created in [[#Setup]] there are a number of files and directories; we are only concerned with a few of these, mainly: <br />
* {{ic|packages.x86_64}} - this is where you list, line by line, the packages you want to have installed, and<br />
* the {{ic|airootfs}} directory - this directory acts as an overlay and it is where you make all the customizations.<br />
<br />
Generally, every administrative task that you would normally do after a fresh install except for package installation can be scripted into {{ic|''archlive''/airootfs/root/customize_airootfs.sh}}. It has to be written from the perspective of the new environment, so {{ic|/}} in the script means the root of the live-iso which is to be created.<br />
<br />
=== Installing packages ===<br />
<br />
[[Edit]] the lists of packages in {{ic|packages.x86_64}} to indicate which packages are to be installed on the live medium.<br />
<br />
{{Note|If you want to use a [[window manager]] in the Live CD then you must add the necessary and correct [[video drivers]], or the WM may freeze on loading.}}<br />
<br />
==== Custom local repository ====<br />
<br />
{{Merge|Pacman tips#Custom local repository|Move the general information (e.g. repo tree) into the main article.}}<br />
<br />
For the purpose of preparing custom packages or packages from [[AUR]]/[[ABS]], you could also [[custom local repository|create a custom local repository]]. If you are looking to support multiple architectures then precautions should be taken to prevent errors from occurring. Each architecture should have its own directory tree:<br />
<br />
{{hc|$ tree ~/customrepo/ {{!}} sed "s/$(uname -m)/<arch>/g"|<br />
/home/archie/customrepo/<br />
└── <arch><br />
├── customrepo.db -> customrepo.db.tar.xz<br />
├── customrepo.db.tar.xz<br />
├── customrepo.files -> customrepo.files.tar.xz<br />
├── customrepo.files.tar.xz<br />
└── personal-website-git-b99cce0-1-<arch>.pkg.tar.xz<br />
<br />
1 directory, 5 files<br />
}}<br />
You can then add your repository by putting the following into {{ic|~/archlive/pacman.conf}}, above the other repository entries (for top priority):<br />
<br />
{{hc|~/archlive/pacman.conf|...<br />
# custom repository<br />
[customrepo]<br />
SigLevel <nowiki>=</nowiki> Optional TrustAll<br />
Server <nowiki>=</nowiki> file:///home/'''user'''/customrepo/$arch<br />
...}}<br />
<br />
The ''repo-add'' executable checks if the package is appropriate. If this is not the case you will be running into error messages similar to this:<br />
<br />
==> ERROR: '/home/archie/customrepo/<arch>/foo-<arch>.pkg.tar.xz' does not have a valid database archive extension.<br />
<br />
==== Preventing installation of packages belonging to base group ====<br />
<br />
By default, {{ic|/usr/bin/mkarchiso}}, a script which is used by {{ic|~/archlive/build.sh}}, calls one of the {{Pkg|arch-install-scripts}} named {{ic|pacstrap}} without the {{ic|-i}} flag, which causes [[Pacman]] to not wait for user input during the installation process.<br />
<br />
When blacklisting base group packages by adding them to the {{ic|IgnorePkg}} line in {{ic|~/archlive/pacman.conf}}, [[Pacman]] asks if they still should be installed, which means they will when user input is bypassed. To get rid of these packages there are several options:<br />
<br />
* '''Dirty''': Add the {{ic|-i}} flag to each line calling {{ic|pacstrap}} in {{ic|/usr/bin/mkarchiso}}.<br />
<br />
* '''Clean''': Create a copy of {{ic|/usr/bin/mkarchiso}} in which you add the flag and adapt {{ic|~/archlive/build.sh}} so that it calls the modified version of the mkarchiso script.<br />
<br />
* '''Advanced''': Create a function for {{ic|~/archlive/build.sh}} which explicitly removes the packages after the base installation. This would leave you the comfort of not having to type enter so much during the installation process.<br />
<br />
==== Installing packages from multilib ====<br />
<br />
To install packages from the [[multilib]] repository simply uncomment the repository in {{ic|~/archlive/pacman.conf}}:<br />
<br />
{{hc|pacman.conf|2=<br />
[multilib]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
}}<br />
<br />
=== Adding files to image ===<br />
<br />
{{Note|You must be root to do this, do not change the ownership of any of the files you copy over, '''everything''' within the airootfs directory must be root owned. Proper ownerships will be sorted out shortly.}}<br />
<br />
The airootfs directory acts as an overlay, think of it as root directory '/' on your current system, so any files you place within this directory will be copied over on boot-up.<br />
<br />
So if you have a set of iptables scripts on your current system you want to be used on you live image, copy them over as such:<br />
# cp -r /etc/iptables ~/archlive/airootfs/etc<br />
<br />
Placing files in the users home directory is a little different. Do not place them within {{ic|airootfs/home}}, but instead create a skel directory within {{ic|airootfs/}} and place them there. We will then add the relevant commands to the {{ic|customize_airootfs.sh}} which we are going to use to copy them over on boot and sort out the permissions.<br />
<br />
First, create the skel directory:<br />
# mkdir ~/archlive/airootfs/etc/skel<br />
<br />
Now copy the 'home' files to the skel directory, e.g for {{ic|.bashrc}}:<br />
# cp ~/.bashrc ~/archlive/airootfs/etc/skel/<br />
<br />
When {{ic|~/archlive/airootfs/root/customize_airootfs.sh}} is executed and a new user is created, the files from the skel directory will automatically be copied over to the new home folder, permissions set right.<br />
<br />
Similarly, some care is required for special configuration files that reside somewhere down the hierarchy. As an example the {{ic|/etc/X11/xinit/xinitrc}} configuration file resides on a path that might be overwritten by installing a package. To place the configuration file one should put the custom {{ic|xinitrc}} in {{ic|~/archlive/airootfs/etc/skel/}} and then modify {{ic|customize_airootfs.sh}} to move it appropriately.<br />
<br />
=== Boot Loader ===<br />
<br />
The default file should work fine, so you should not need to touch it.<br />
<br />
Due to the modular nature of isolinux, you are able to use lots of addons since all *.c32 files are copied and available to you. Take a look at the [http://syslinux.zytor.com/wiki/index.php/SYSLINUX official syslinux site] and the [https://projects.archlinux.org/archiso.git/tree/configs/syslinux-iso/boot-files archiso git repo]. Using said addons, it is possible to make visually attractive and complex menus. See [http://syslinux.zytor.com/wiki/index.php/Comboot/menu.c32 here].<br />
<br />
==== UEFI SecureBoot ====<br />
<br />
If you want to make your Archiso bootable on a UEFI Secure Boot enabled environment, you must use a signed bootloader. You can either follow the instructions on [[Secure Boot#Using a signed boot loader]] or you can use a bootloader of another distro with a old enough presigned bootloader, for example [http://releases.ubuntu.com/16.04/ Ubuntu 16.04]. If you choose to use the presigned EFI bootloader from Ubuntu, you first need to acquire the {{ic|/EFI/BOOT/}} and {{ic|/boot/}} folders from the Ubuntu ISO image. Then you need to edit the functions {{ic|make_efi()}} and {{ic|make_efiboot()}} in {{ic|~/archlive/build.sh}} to install the Ubuntu's GRUB bootloader instead of installing systemd bootloader. You should also edit the {{ic|/boot/grub/grub.cfg}} so that GRUB tries to boot your Archiso instead of Ubuntu.<br />
<br />
=== Login manager ===<br />
<br />
Starting X at boot is done by enabling your login manager's [[systemd]] service. If you know which .service file needs a softlink: Great. If not, you can easily find out in case you are using the same program on the system you build your iso on. Just use:<br />
<br />
$ ls -l /etc/systemd/system/display-manager.service<br />
<br />
Now create the same softlink in {{ic|~/archlive/airootfs/etc/systemd/system}}. For LXDM:<br />
<br />
# ln -s /usr/lib/systemd/system/lxdm.service ~/archlive/airootfs/etc/systemd/system/display-manager.service<br />
<br />
This will enable LXDM at system start on your live system.<br />
<br />
Alternatively you can just enable the service in {{ic|airootfs/root/customize_airootfs.sh}} along with other services that are enabled there.<br />
<br />
If you want the graphical environment to actually start automatically during boot make sure to edit {{ic|airootfs/root/customize_airootfs.sh}} and replace <br />
<br />
systemctl set-default multi-user.target<br />
with<br />
systemctl set-default graphical.target<br />
<br />
=== Changing Automatic Login ===<br />
<br />
The configuration for getty's automatic login is located under {{ic|airootfs/etc/systemd/system/getty@tty1.service.d/autologin.conf}}.<br />
<br />
You can modify this file to change the auto login user:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=-/sbin/agetty --autologin '''isouser''' --noclear %I 38400 linux<br />
<br />
Or remove it altogether to disable auto login.<br />
<br />
== Build the ISO ==<br />
<br />
Now you are ready to turn your files into the .iso which you can then burn to CD or USB:<br />
<br />
First create the {{ic|out/}} directory (optional, build.sh will create it if nonexist),<br />
<br />
# mkdir ~/archlive/out/<br />
<br />
then inside {{ic|~/archlive}}, execute:<br />
<br />
# ./build.sh -v<br />
<br />
The script will now download and install the packages you specified to {{ic|work/*/airootfs}}, create the kernel and init images, apply your customizations and finally build the iso into {{ic|out/}}.<br />
<br />
=== Rebuild the ISO ===<br />
<br />
Rebuilding the iso after modifications is not officially supported. However, it is easily possible by applying two steps. First you have to remove lock files in the work directory:<br />
<br />
# rm -v work/build.make_*<br />
<br />
Furthermore it is required to edit the script {{ic|airootfs/root/customize_airootfs.sh}}, and add an {{ic|id}} command in the beginning of the {{ic|useradd}} line as shown here. Otherwise the rebuild stops at this point because the user that is to be added already exists {{Bug|41865}}.<br />
<br />
{{Style|typo?}}<br />
<br />
! id arch && useradd -m -p "" -g users -G "adm,audio,floppy,log,network,rfkill,scanner,storage,optical,power,wheel" -s /usr/bin/zsh arch<br />
<br />
Also remove persistent data such as created users or symlinks such as {{ic|/etc/sudoers}}.<br />
<br />
{{Expansion|Report more data that needs to be removed or reset.}}<br />
<br />
Rebuilds can be sped up slightly by editing the pacstrap script (located at /bin/pacstrap) and changing the following at line 361:<br />
<br />
Before:<br />
<br />
if ! pacman -r "$newroot" -Sy "${pacman_args[@]}"; then<br />
<br />
After:<br />
<br />
if ! pacman -r "$newroot" -Sy --needed "${pacman_args[@]}"; then<br />
<br />
This increases the speed of the initial bootstrap, since it does not have to download and install any of the base packages that are already installed.<br />
<br />
== Using the ISO ==<br />
<br />
See the [[:Category:Getting and installing Arch#Installation methods]] section for various options.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Installation without Internet access ===<br />
<br />
{{Move|Installation without Internet access|seems like this could stand alone}}<br />
{{Accuracy|Instead of copying the files from the archiso, the "bootstrap" images available on the Arch mirrors can be extracted directly to the target disk. You will get a minimal system without the need to deal with the archiso modifications.}}<br />
<br />
If you wish to install the archiso (e.g. [https://www.archlinux.org/download/ the official monthly release]) as it is without an Internet connection, or, if you do not want to download the packages you want again:<br />
<br />
First, follow the [[Installation guide]], skipping the [[Installation guide#Connect to the Internet]] section, until the [[Installation guide#Install the base packages]] step.<br />
<br />
==== Install the archiso to the new root ====<br />
Instead of installing the packages with {{ic|pacstrap}} (which would try to download from the remote repositories), copy ''everything'' in the live environment to the new root:<br />
# cp -ax / /mnt<br />
{{Note|The option ({{ic|-x}}) excludes some special directories, as they should not be copied to the new root.}}<br />
Then, copy the kernel image to the new root, in order to keep the integrity of the new system:<br />
# cp -vaT /run/archiso/bootmnt/arch/boot/$(uname -m)/vmlinuz /mnt/boot/vmlinuz-linux<br />
<br />
After that, generate a fstab as described in [[Installation guide#Fstab]].<br />
<br />
==== Chroot and configure the base system ====<br />
Next, chroot into your newly installed system:<br />
# arch-chroot /mnt /bin/bash<br />
<br />
{{Note|Before performing the other [[Installation guide#Configure the system]] steps (e.g. locale, keymap, etc.), it is necessary to get rid of the trace of the Live environment (in other words, the customization of archiso which does not fit a non-Live environment).}}<br />
<br />
===== Restore the configuration of journald =====<br />
[https://projects.archlinux.org/archiso.git/tree/configs/releng/airootfs/root/customize_airootfs.sh#n19 This customization of archiso] will lead to storing the system journal in RAM, it means that the journal will not be available after reboot:<br />
# sed -i 's/Storage=volatile/#Storage=auto/' /etc/systemd/journald.conf<br />
<br />
===== Remove special udev rule =====<br />
[https://projects.archlinux.org/archiso.git/tree/configs/releng/airootfs/etc/udev/rules.d/81-dhcpcd.rules This rule of udev] starts the dhcpcd automatically if there are any wired network interfaces.<br />
<br />
# rm /etc/udev/rules.d/81-dhcpcd.rules<br />
<br />
===== Disable and remove the services created by archiso =====<br />
Some service files are created for the Live environment, please disable the services and remove the file as they are unnecessary for the new system:<br />
# systemctl disable pacman-init.service choose-mirror.service<br />
# rm -r /etc/systemd/system/{choose-mirror.service,pacman-init.service,etc-pacman.d-gnupg.mount,getty@tty1.service.d}<br />
# rm /etc/systemd/scripts/choose-mirror<br />
<br />
===== Remove special scripts of the Live environment =====<br />
There are some scripts installed in the live system by archiso scripts, which are unnecessary for the new system:<br />
# rm /etc/systemd/system/getty@tty1.service.d/autologin.conf<br />
# rm /root/{.automated_script.sh,.zlogin}<br />
# rm /etc/mkinitcpio-archiso.conf<br />
# rm -r /etc/initcpio<br />
<br />
===== Importing archlinux keys =====<br />
<br />
In order to use the official repositories, we need to import the archlinux master keys ([[pacman/Package signing#Initializing the keyring]]). This step is usually done by pacstrap but can be achieved with<br />
<br />
# pacman-key --init<br />
# pacman-key --populate archlinux<br />
<br />
{{Note| Keyboard or mouse activity is needed to generate entropy and speed-up the first step.}}<br />
<br />
===== Configure the system =====<br />
<br />
Now you can follow the skipped steps of the [[Installation guide#Configure the system]] section (setting a locale, timezone, hostname, etc.) and finish the installation by creating an initial ramdisk as described in [[Installation guide#Initramfs]].<br />
<br />
===== Enable graphical login (optional) =====<br />
<br />
If using a display manager like GDM, you may want to change the systemd default target from multi-user.target to one that allows graphical login.<br />
# systemctl disable multi-user.target<br />
# systemctl enable graphical.target<br />
<br />
== See also ==<br />
=== Documentation and tutorials ===<br />
* [https://projects.archlinux.org/archiso.git Archiso project page]<br />
* [https://projects.archlinux.org/archiso.git/tree/docs Official documentation]<br />
<br />
=== Example customization template ===<br />
* [http://easy.open.and.free.fr/didjix/ A live DJ distribution powered by ArchLinux and built with Archiso]<br />
<br />
=== Creating a offline installation ISO ===<br />
* [[Archiso offline]]</div>Jussihi