https://wiki.linuxquestions.org/api.php?action=feedcontributions&user=Hazel&feedformat=atomLQWiki - User contributions [en]2024-03-28T22:53:23ZUser contributionsMediaWiki 1.37.0https://wiki.linuxquestions.org/index.php?title=Su&diff=69433Su2023-03-24T17:27:03Z<p>Hazel: /* Usage */</p>
<hr />
<div>The '''su''' [[command]] allows the current user to assume the identity of another user on a [[Linux]] system. It stands for "switch user" or "substitute user", ''not'' "superuser" (although it defaults to prompting for the [[root]] password if invoked without any arguments). The <tt>su</tt> command is very useful in [[Unix]].<br />
<br />
== Usage ==<br />
<pre><br />
$ su [user]<br />
</pre><br />
<br />
When an ordinary user invokes the <tt>su</tt> command they will be prompted for the password of the user whose account they are attempting to utilise. Once a correct password is entered, the [[shell]] prompt will return and the user will now be operating with the [[permission]]s and access privileges of the target account. If the command <tt>su -</tt> is used (with a single dash as the argument) the user will also inherit the environment of the target user (as if they had logged in using the target user's ID and password).<br />
<br />
If you invoke the <tt>su</tt> command ''as root'', in order to assume the identity of another user, you will will not be asked for that user's password. This means that anyone who knows the root password can in practice assume the identity of any user.<br />
<br />
It is often suggested that as a precaution when using <tt>su</tt> to execute commands as the root user, that the command be invoked in the form:<br />
<br />
<pre><br />
$ su -c command [user]<br />
</pre><br />
<br />
When executed in this form, if authentication is successful, <tt>su</tt> will return immediately after executing <tt>command</tt> as the other user, without launching a shell as the target user. If the target user is root, this method of execution will avoid problems caused by accidentally leaving a root shell open on the system.<br />
<br />
In most shells <tt>command</tt> must be contained within quotation marks if it contains special characters or spaces.<br />
<br />
As an example, an unprivileged user might execute the following command to edit the [[LILO]] configuration file:<br />
<br />
<pre><br />
$ su -c "vi /etc/lilo.conf"<br />
</pre><br />
<br />
The [[sudo]] command is similar but only allows for the running of a single command as root, and allows control over which users are allowed access to what commands.<br />
<br />
== Provided by ==<br />
<br />
Most (all?) Linux distributions incorporate this from the [http://www.gnu.org/software/coreutils/manual/html_node/index.html#Top GNU Coreutils]: and use its man<br />
[http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html page]<br />
<br />
<br />
== Provided by ==<br />
Most (all?) Linux distributions incorporate this from the [[https://www.kernel.org/pub/linux/utils/util-linux/ util-linux]] project.<br />
<br />
== Related Commands ==<br />
These all relate to running commands in an altered context.<br />
* <tt>[[chroot]]</tt> - Confine the program to "jail".<br />
* <tt>[[env(command)|env]]</tt> - Change variables.<br />
* <tt>[[gdb]]</tt> - Run under control of a debugger<br />
* <tt>[[nice]]</tt> - Change priority.<br />
* <tt>[[nohup]]</tt> - Protect from hangups (modem) or network outages.<br />
* <tt>[[runuser]]</tt> - Used by root to run a command as an ordinary user<br />
* <tt>[[script]]</tt> - Capture all program output<br />
* <tt>[[stdbuf]]</tt> - Change buffering of standard I/O filestreams.<br />
* <tt>[[strace]]</tt> - Create a log of system calls.<br />
* <tt>[[timeout]]</tt> - Limit the time.<br />
* <tt>[[valgrind]]</tt> - Validate program behavior<br />
<br />
<br />
==See also==<br />
*[[security]]<br />
<br />
{{stub}}<br />
<br />
[[Category:Command]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Cmake&diff=69432Cmake2023-03-23T18:04:59Z<p>Hazel: /* Cmake */</p>
<hr />
<div>==Cmake==<br />
The '''cmake''' program is a software building tool which provides an alternative to traditional package-specific configuration scripts. It is designed to work on different software platforms.<br />
<br />
Like a configure script, cmake interrogates the system on which the package is to be built and makes decisions based on the supporting software that it finds. The actual building of the package must then be carried out by a separate program such as [[make]] or [[ninja]].</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Cmake&diff=69431Cmake2023-03-23T18:03:16Z<p>Hazel: stub article for cmake</p>
<hr />
<div>==Cmake==<br />
The cmake program is a software building tool which provides an alternative to traditional package-specific configuration scripts. It is designed to work on different software platforms.<br />
<br />
Like a configure script, cmake interrogates the system on which the package is to be built and makes decisions based on the supporting software that it finds. The actual building of the package must then be carried out by a separate program such as [[make]] or [[ninja]].</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Mkdir&diff=69375Mkdir2022-09-27T11:51:01Z<p>Hazel: </p>
<hr />
<div>'''mkdir''' is the command used to create directories. To use it successfully, you need write access to the parent directory. The syntax is <tt>mkdir <i>options</i> dirname</tt>. The option '''-m''' specifies the mode (permissions) of the created directory and '''-p''' creates a directory tree with any necessary parent directories. For instance, <tt>mkdir -p parent/child</tt> creates both directories in a single operation. If the parent(s) already exist, there is no error. The '''-v''' option makes the operation more verbose.<br />
<br />
Contrary to the misleading desktop metaphor, a directory is not really a 'folder'. A cardboard folder physically <i>contains</i> paper files. A directory does not contain its files, but is simply a special type of file that indexes other files (including other directories). It contains a list of names mapped to [[inode]] numbers which locate the files on disk. <br />
<br />
A directory always contains at least the two entries: '.' (which refers to itself) and '..' (which refers to its parent). Unless it is the [[root directory]] on its [[volume]], in which case its '..' refers to itself, just as '.' does.<br />
<br />
Many people are used to using <tt>md</tt> as the command to make directories, so it is often [[alias]]ed.<br />
alias md=mkdir # In [[bash]], etc.<br />
alias md mkdir # In [[tcsh]], etc.<br />
<br />
= Provided by =<br />
<br />
Most (all?) Linux distributions incorporate this from the [http://www.gnu.org/software/coreutils/manual/html_node/index.html#Top GNU Coreutils]: man<br />
[http://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html page]<br />
<br />
= Related Commands =<br />
* [[link]] - Make hard links.<br />
* [[ln]] - Make hard or soft links<br />
* [[readlink]] - Make a canonical name.<br />
* [[rmdir]] - Remove empty directories.<br />
<br />
= See Also =<br />
* [[file (concept)|file]]<br />
* [[device]]<br />
* [[Directory]]<br />
<br />
== External links ==<br />
* Another [http://linux.die.net/man/3/mkdir mkdir man page]<br />
<br />
{{stub}}<br />
<br />
[[Category:Command]]<br />
[[Category:Filehandling]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Mkdir&diff=69374Mkdir2022-09-27T11:48:21Z<p>Hazel: </p>
<hr />
<div>'''mkdir''' is the command used to create directories. The syntax is <tt>mkdir <i>options</i> dirname</tt>. The option '''-m''' specifies the mode (permissions) of the created directory and '''-p''' creates a directory tree with any necessary parent directories. For instance, <tt>mkdir -p parent/child</tt> creates both directories in a single operation. If the parent(s) already exist, there is no error. The '''-v''' option makes the operation more verbose.<br />
<br />
Contrary to the misleading desktop metaphor, a directory is not really a 'folder'. A cardboard folder physically <i>contains</i> paper files. A directory does not contain its files, but is simply a special type of file that indexes other files (including other directories). It contains a list of names mapped to [[inode]] numbers which locate the files on disk. <br />
<br />
A directory always contains at least the two entries: '.' (which refers to itself) and '..' (which refers to its parent). Unless it is the [[root directory]] on its [[volume]], in which case its '..' refers to itself, just as '.' does.<br />
<br />
Many people are used to using <tt>md</tt> as the command to make directories, so it is often [[alias]]ed.<br />
alias md=mkdir # In [[bash]], etc.<br />
alias md mkdir # In [[tcsh]], etc.<br />
<br />
= Provided by =<br />
<br />
Most (all?) Linux distributions incorporate this from the [http://www.gnu.org/software/coreutils/manual/html_node/index.html#Top GNU Coreutils]: man<br />
[http://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html page]<br />
<br />
= Related Commands =<br />
* [[link]] - Make hard links.<br />
* [[ln]] - Make hard or soft links<br />
* [[readlink]] - Make a canonical name.<br />
* [[rmdir]] - Remove empty directories.<br />
<br />
= See Also =<br />
* [[file (concept)|file]]<br />
* [[device]]<br />
* [[Directory]]<br />
<br />
== External links ==<br />
* Another [http://linux.die.net/man/3/mkdir mkdir man page]<br />
<br />
{{stub}}<br />
<br />
[[Category:Command]]<br />
[[Category:Filehandling]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Mkdir&diff=69373Mkdir2022-09-27T11:45:08Z<p>Hazel: </p>
<hr />
<div>'''mkdir''' is the command used to create directories. The syntax is <tt>mkdir <i>options</i> dirname</tt>. The option '''-m''' specifies the mode (permissions) of the created directory and '''-p''' creates any parents - for instance, <tt>mkdir -p parent/child</tt> creates both directories.<br />
<br />
Contrary to the misleading desktop metaphor, a directory is not really a 'folder'. A cardboard folder physically <i>contains</i> paper files. A directory does not contain its files, but is simply a special type of file that indexes other files (including other directories). It contains a list of names mapped to [[inode]] numbers which locate the files on disk. <br />
<br />
A directory always contains at least the two entries: '.' (which refers to itself) and '..' (which refers to its parent). Unless it is the [[root directory]] on its [[volume]], in which case its '..' refers to itself, just as '.' does.<br />
<br />
Many people are used to using <tt>md</tt> as the command to make directories, so it is often [[alias]]ed.<br />
alias md=mkdir # In [[bash]], etc.<br />
alias md mkdir # In [[tcsh]], etc.<br />
<br />
= Provided by =<br />
<br />
Most (all?) Linux distributions incorporate this from the [http://www.gnu.org/software/coreutils/manual/html_node/index.html#Top GNU Coreutils]: man<br />
[http://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html page]<br />
<br />
= Related Commands =<br />
* [[link]] - Make hard links.<br />
* [[ln]] - Make hard or soft links<br />
* [[readlink]] - Make a canonical name.<br />
* [[rmdir]] - Remove empty directories.<br />
<br />
= See Also =<br />
* [[file (concept)|file]]<br />
* [[device]]<br />
* [[Directory]]<br />
<br />
== External links ==<br />
* Another [http://linux.die.net/man/3/mkdir mkdir man page]<br />
<br />
{{stub}}<br />
<br />
[[Category:Command]]<br />
[[Category:Filehandling]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Mkdir&diff=69372Mkdir2022-09-27T11:44:29Z<p>Hazel: </p>
<hr />
<div>'''mkdir''' is the command used to create directories. The syntax is <tt>mkdir <i>options</i> dirname</tt>. The option '''-m''' specifies the mode (permissions) of the created directory and '''-p''' creates any parents - for instance, <tt>mkdir -p parent/child</tt> creates both directories.<br />
<br />
Contrary to the misleading desktop metaphor, a directory is not really a 'folder'. A paper folder physically <i>contains</i> paper files. A directory does not contain its files, but is simply a special type of file that indexes other files (including other directories). It contains a list of names mapped to [[inode]] numbers which locate the files on disk. <br />
<br />
A directory always contains at least the two entries: '.' (which refers to itself) and '..' (which refers to its parent). Unless it is the [[root directory]] on its [[volume]], in which case its '..' refers to itself, just as '.' does.<br />
<br />
Many people are used to using <tt>md</tt> as the command to make directories, so it is often [[alias]]ed.<br />
alias md=mkdir # In [[bash]], etc.<br />
alias md mkdir # In [[tcsh]], etc.<br />
<br />
= Provided by =<br />
<br />
Most (all?) Linux distributions incorporate this from the [http://www.gnu.org/software/coreutils/manual/html_node/index.html#Top GNU Coreutils]: man<br />
[http://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html page]<br />
<br />
= Related Commands =<br />
* [[link]] - Make hard links.<br />
* [[ln]] - Make hard or soft links<br />
* [[readlink]] - Make a canonical name.<br />
* [[rmdir]] - Remove empty directories.<br />
<br />
= See Also =<br />
* [[file (concept)|file]]<br />
* [[device]]<br />
* [[Directory]]<br />
<br />
== External links ==<br />
* Another [http://linux.die.net/man/3/mkdir mkdir man page]<br />
<br />
{{stub}}<br />
<br />
[[Category:Command]]<br />
[[Category:Filehandling]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68645How to use Secure Boot with your own keys2021-07-31T13:56:20Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is the unsigned elilo binary and the signed version is put into /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br><br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br><br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br><br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68644How to use Secure Boot with your own keys2021-07-31T13:55:46Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is the unsigned elilo binary and the signed version is put into /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br><br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br><br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68643How to use Secure Boot with your own keys2021-07-31T13:54:49Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is the unsigned elilo binary and the signed version is put into /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br><br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68642How to use Secure Boot with your own keys2021-07-31T13:54:07Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is the unsigned elilo binary and the signed version is put into /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br><br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68641How to use Secure Boot with your own keys2021-07-31T13:53:25Z<p>Hazel: /* Installing the keys */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is the unsigned elilo binary and the signed version is put into /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68640How to use Secure Boot with your own keys2021-07-31T13:51:04Z<p>Hazel: /* Creating new keys */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68639How to use Secure Boot with your own keys2021-07-31T13:50:18Z<p>Hazel: /* Clearing the existing keys */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it never hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68638How to use Secure Boot with your own keys2021-07-31T13:49:07Z<p>Hazel: /* Install the keys */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Installing the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68637How to use Secure Boot with your own keys2021-07-31T13:48:01Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
#*gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If your distro often updates grub.cfg, then it is better to embed some simple initial configuration file and load grub.cfg from there, so that the GRUB binary does not need to be regenerated and resigned every time.<br />
<br />
Example:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it! Your kernel should now boot in secure mode.<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" your system you may want to add a password to GRUB, otherwise anyone who has physical access can just go to the GRUB command line and enter:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
Setting a password prevents this.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68636How to use Secure Boot with your own keys2021-07-31T13:43:58Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
#*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
#*set check_signatures=enforce<br />
#*export check_signatures<br />
#Sign grub.cfg:<br />
**gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
#*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
#*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68635How to use Secure Boot with your own keys2021-07-31T13:41:16Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: \<br />
gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:\<br />
**set check_signatures=enforce<br />
**export check_signatures<br />
#Sign grub.cfg:<br />
**gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
**grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
**sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68634How to use Secure Boot with your own keys2021-07-31T13:37:17Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
**gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
**set check_signatures=enforce<br />
**export check_signatures<br />
#Sign grub.cfg:<br />
**gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
**grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
**sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68633How to use Secure Boot with your own keys2021-07-31T13:36:34Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
*gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
*set check_signatures=enforce<br />
*export check_signatures<br />
#Sign grub.cfg:<br />
* gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
*grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
*sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68632How to use Secure Boot with your own keys2021-07-31T13:35:51Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
.gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
.set check_signatures=enforce<br />
.export check_signatures<br />
#Sign grub.cfg:<br />
. gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
.grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
.sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68631How to use Secure Boot with your own keys2021-07-31T13:31:53Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: //gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg://<br />
set check_signatures=enforceexport check_signatures<br />
#Sign grub.cfg://<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it://<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68630How to use Secure Boot with your own keys2021-07-31T13:29:49Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: //<br />
gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg://<br />
set check_signatures=enforceexport check_signatures<br />
#Sign grub.cfg://<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:\\<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it://<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68629How to use Secure Boot with your own keys2021-07-31T13:27:48Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:<br />
set check_signatures=enforce<br />
export check_signatures<br />
#Sign grub.cfg: gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68628How to use Secure Boot with your own keys2021-07-31T13:26:46Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:set <br />
check_signatures=enforce<br />
export check_signatures<br />
#Sign grub.cfg: gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68627How to use Secure Boot with your own keys2021-07-31T13:26:13Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: gpg --export <KEY_ID> gpg.key<br />
#Add this to the begining of your grub.cfg:set <br />
check_signatures=enforce<br />
export check_signatures<br />
#Sign grub.cfg:<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
#Sign it:<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68626How to use Secure Boot with your own keys2021-07-31T13:25:40Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: gpg --export <KEY_ID> gpg.key<br />
<br />
#Add this to the begining of your grub.cfg:set <br />
check_signatures=enforce<br />
export check_signatures<br />
<br />
#Sign grub.cfg:<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
<br />
#Sign it:<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68625How to use Secure Boot with your own keys2021-07-31T13:24:26Z<p>Hazel: /* Securing the kernel using the GRUB bootloader */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key: <br />
gpg --export <KEY_ID> gpg.key<br />
<br />
#Add this to the begining of your grub.cfg:<br />
set check_signatures=enforce<br />
export check_signatures<br />
<br />
#Sign grub.cfg:<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
<br />
#Sign it:<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68624How to use Secure Boot with your own keys2021-07-31T13:22:55Z<p>Hazel: /* Install the keys */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and your system should boot normally.<br />
<br />
==Securing the kernel using the GRUB bootloader==<br />
<br />
Because elilo doesn't support secure boot, your kernel is not booted in secure mode and therefore the kernel and initrd do not need to be signed.<br />
If you consider this a security risk and want to boot the kernel in secure mode, you will need to use GRUB as your bootloader. GRUB is in any case the bootloader that most distros use by default. When GRUB is booted using secure boot, it will detect this and won't load an unsigned kernel. To override this behaviour, you can put the following into grub.cfg:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
But it is better to make use of GRUB's ability to boot securely by properly signing your kernel. GRUB supports only GPG signatures, so you will have to use GPG to sign the kernel and initrd and also any GRUB modules that you will need. You can use an existing gpg key or create a new one with gpg --gen-key ...<br />
<br />
#Export the GPG key:<br />
<br />
gpg --export <KEY_ID> gpg.key<br />
<br />
#Add this to the begining of your grub.cfg:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
<br />
#Sign grub.cfg:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
<br />
#Create single grub binary by embedding the modules that are required for your hardware configuration into GRUB itself:<br />
<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
<br />
#Sign it:<br />
<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68623How to use Secure Boot with your own keys2021-07-31T13:06:05Z<p>Hazel: /* Clearing the existing keys */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries<br />
<br />
==Creating new keys==<br />
You must start by creating a GUID (a randomly generated code). There are a number of programs that can do this. A well-known one is uuidgen from dbus.<br />
<br />
uuidgen --random > guid.txt<br />
<br />
Create a new Playtform Key (PK) keypair, key-exchange (KEK) keypair and signing (DB) keypair:<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout pk.key -out pk.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Key Exchange Key/" -keyout kek.key -out kek.crt -days 3650 -nodes -sha256<br />
#openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Signature DB Key/" -keyout db.key -out db.crt -days 3650 -nodes -sha256<br />
<br />
Now create the "EFI signature list" version of PK by using the .crt file alongside the GUID. The efi-updatevar program requires this format.<br />
<br />
<br />
cert-to-efi-sig-list -g "$(< guid.txt)" pk.crt pk.esl<br />
<br />
Sign it with created private key:<br />
<br />
sign-efi-sig-list -k pk.key -c pk.crt PK pk.esl pk.auth<br />
<br />
Create the KEK and DB keys in the same way:<br />
<br />
<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" kek.crt kek.esl<br />
#cert-to-efi-sig-list -g "$(< guid.txt)" db.crt db.esl<br />
<br />
Now create combined lists containing the new key plus the default keys:<br />
<br />
<br />
#cat old_KEK.esl kek.esl > combined_KEK.esl<br />
#cat old_db.esl db.esl > combined_db.esl<br />
<br />
==Install the keys==<br />
<br />
#efi-updatevar -e -f old_dbx.esl dbx<br />
#efi-updatevar -e -f combined_db.esl db<br />
#efi-updatevar -e -f combined_KEK.esl KEK<br />
#efi-updatevar -f pk.auth PK<br />
<br />
Note that the keys must be added in reverse order of significance: the database keys first, then the Key Exchange Key and finally the Platform Key. This is because setting a Platform Key locks the secure boot setup and should automatically return you to user mode.<br />
<br />
You can verify with efi-readvar, that all keys are installed.<br />
<br />
Note: Instead of using efi-updatevar, you could boot into UEFI setup and load your keys there, but some firmware is picky about key formats.<br />
Some will accept .esl, others require DER format. efi-updatevar is better tempered.<br />
<br />
Finally sign your boot loader:<br />
<br />
for example, in Slackware: sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/elilo-x86_64.efi /boot/elilo-x86_64.efi<br />
<br />
elilo-x86_64.efi is name of the EFI boot loader that Slackware generally uses.<br />
In this example /boot/elilo-x86_64.efi is unsinged elilo binary and signed is put to /boot/efi/EFI/Slackware/elilo-x86_64.efi<br />
<br />
You can now reboot and enable Secure boot and it should boot with secure boot enabled.<br />
<br />
Because elilo doesn't support secure boot, kernel is not booted in secure mode and kernel/initrd doesn't need to be signed.<br />
But to properly boot kernel in secure mode GRUB must be used.<br />
<br />
If you use GRUB, signing GRUB is not enough, it will detect secure boot and won't load unsigned kernel.<br />
One option is to put this in grub.cfg:<br />
<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
but better is to properly sign kernel. But AFAIK grub only support GPG signature.<br />
So kernel and initrd (and all grub modules) must be signed with GPG.<br />
<br />
This is how I do it, this is specific to my configuration.<br />
I just create single GRUB binary with modules and config embedded:<br />
<br />
You can use existing gpg key or create new one gpg --gen-key ...<br />
<br />
Export GPG key:<br />
Code:<br />
<br />
gpg --export <KEY_ID> gpg.key<br />
<br />
Add this to grub.cfg at the begining:<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
<br />
Sign grub.cfg:<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/grub/grub.cfg<br />
<br />
Create single grub binary:<br />
Code:<br />
<br />
grub-mkstandalone --disable-shim-lock --format x86_64-efi --fonts="dejavusansmono" --modules "part_gpt part_msdos fat ext2 gcry_sha512 gcry_rsa password_pbkdf2 pbkdf2 echo normal linux font all_video search search_fs_uuid reboot sleep" --pubkey gpg.key --output "bootx64.efi" "boot/grub/grub.cfg=/boot/grub/grub.cfg" "boot/grub/grub.cfg.sig=/boot/grub.cfg.sig"<br />
<br />
Sign it:<br />
Code:<br />
<br />
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/Slackware/bootx64.efi bootx64.efi<br />
<br />
I just create grub.cfg once and never changed it.<br />
If you often change grub.cfg then it's better to embed some simple initial configuration file and load grub.cfg from there, so grub binary doesn't need to be regenerated and resigned every time, for ex:.<br />
<br />
Code:<br />
<br />
set check_signatures=enforce<br />
export check_signatures<br />
search --no-floppy --fs-uuid --set=root <EFI-UUID|or where config is><br />
configfile /grub.cfg<br />
echo Boting failed, rebooting the system in 10 seconds...<br />
sleep 10<br />
reboot<br />
<br />
Call it grub.init.cfg and embed this file with grub-mkstandalone.<br />
<br />
Now every time kernel is updated it needs to be signed:<br />
<br />
Code:<br />
<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/bzImage<br />
gpg --default-key <KEY_ID> --detach-sign /boot/efi/EFI/Slackware/initrd.gz<br />
<br />
<br />
And that's it. Kernel should now boot in secure mode.<br />
<br />
Code:<br />
<br />
dmesg | grep -i secure<br />
[ 0.006890] Secure boot enabled<br />
<br />
But to really "secure" system you may want to add password to GRUB, otherwise if someone has physical access it can just go to GRUB cmd line and enter:<br />
Code:<br />
<br />
set check_signatures=no<br />
export check_signatures<br />
<br />
If password is set this is prevented.<br />
linux davjohn is offline Add to davjohn's Reputation Report This Post Reply With Quote Multi-Quote This Message<br />
7 members found this post helpful.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68622How to use Secure Boot with your own keys2021-07-31T12:47:38Z<p>Hazel: /* Preparations */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. Only someone physically present with access to the UEFI setup program can do so.<br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68621How to use Secure Boot with your own keys2021-07-31T12:46:02Z<p>Hazel: /* Preparations */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional packages: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. <br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68620How to use Secure Boot with your own keys2021-07-31T11:32:32Z<p>Hazel: /* What is secure boot? */</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload [[GRUB]] and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional programs: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. <br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68619How to use Secure Boot with your own keys2021-07-31T11:14:14Z<p>Hazel: </p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload GRUB and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional programs: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. <br />
<br />
Note that these are public cryptographic keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine, where they could potentially be read by bad actors.<br />
<br />
==Clearing the existing keys==<br />
To do this, you must reboot into the UEFI firmware. Your bootloader may give you an option to do this; if not, you will have to use your computer's "magic key" to break into the UEFI's setup mode. <br />
<br />
Start by removing the default Secure Boot keys. How exactly this is done depends on the firmware. You may need to explore the menu system of your UEFI setup program. Removing the keys will automatically switch Secure Boot into its "Setup" mode. Here again there is often an option to save the default keys, The firmware may also have an option to restore default keys, but it nver hurts to have more backups!<br />
<br />
Now boot back into Linux.<br />
<br />
You can check that secure variables are empty:<br />
<br />
efi-readvar should output:<br />
<br />
*Variable PK has no entries<br />
*Variable KEK has no entries<br />
*Variable db has no entries<br />
*Variable dbx has no entries</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68618How to use Secure Boot with your own keys2021-07-31T11:03:04Z<p>Hazel: </p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload GRUB and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional programs: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. C<br />
Note that these are public keys (see [[HOWTO Create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68617How to use Secure Boot with your own keys2021-07-31T11:00:32Z<p>Hazel: </p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload GRUB and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional programs: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. <br />
<br />
Note that these are public keys (see [[HOWTO create ssh keys]]). The corresponding private keys that are actually used for signing software are not stored anywhere on the machine.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68616How to use Secure Boot with your own keys2021-07-31T10:57:40Z<p>Hazel: </p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which is often a requirement for school work, and which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's shim program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload GRUB and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.<br />
<br />
==Preparations==<br />
Modifying your computer's UEFI variables is potentially dangerous. It could leave your computer unbootable. The method described here has been used successfully by its author on multiple laptop and desktop computers and it worked without problems, but you use it at your own risk. To reduce the risks somewhat, the original firmware keys will be kept alongside the new ones, so that Windows and everything signed with Microsoft keys will still work. Some computers have device firmware signed with the Microsoft key which will not work if that key is removed from the database.<br />
<br />
You will need to obtain and install two additional programs: efitools and sbsigntools.<br />
<br />
Start by saving the current keys, using efi-readvar from efitools:<br />
# efi-readvar -v PK -o old_PK.esl<br />
# efi-readvar -v KEK -o old_KEK.esl<br />
# efi-readvar -v db -o old_db.esl<br />
# efi-readvar -v dbx -o old_dbx.esl<br />
<br />
PK is the top-level Platform Key supplied by the manufacturer. It is used to sign the Key Exchange Key or KEK, which is then used to sign the keys stored in the key database (db) and the blacklist (dbx). This chain of trust makes it impossible for malware to insert a new key. <br />
<br />
Note that these are public keys. The private keys that are actually used for signing software are not stored anywhere on the machine.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=How_to_use_Secure_Boot_with_your_own_keys&diff=68615How to use Secure Boot with your own keys2021-07-31T10:40:47Z<p>Hazel: Created page with "How to use Secure Boot with your own keys ==What is secure boot?== All modern computers come with a UEFI instead of a traditional BIOS. One of the facilities which this f..."</p>
<hr />
<div>How to use Secure Boot with your own keys<br />
<br />
==What is secure boot?==<br />
All modern computers come with a [[UEFI]] instead of a traditional BIOS. One of the facilities which this firmware provides is secure boot, meaning that only authorised software can be booted. In the generation of PCs that came with Windows 8, secure boot could be disabled inside the UEFI setup program, but some Windows 10 PCs no longer allow this and it was never allowed on ARM devices.<br />
<br />
How then can Linux be booted on such computers? There are basically three possibilities.<br />
* Switch secure boot off. This is the simplest solution but not always possible (see above) or practical. For example, you may need to dual-boot with Windows, which requires secure boot to be active.<br />
* Use intermediate software like Red Hat's [[shim]] program which is used by a number of distros. This is a binary signed by Microsoft with the key they use for foreign software, which means that it will boot with secure boot enabled. shim will then chainload GRUB and booting can proceed as normal. shim uses a stored user-defined key called a Machine Owner Key or MOK to sign both GRUB and the kernels that GRUB boots, preserving the chain of trust. However many distros do not include shim or the mokmanager program needed to work with MOKs, and they must be obtained from elsewhere.<br />
* Edit the UEFI's own key database in order to add a personal key, and then use it to sign your bootloader, which does not necessarily need to be GRUB. This is the subject of the present article.</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Howto&diff=68614Howto2021-07-31T10:19:36Z<p>Hazel: /* System Administration */</p>
<hr />
<div>A '''Howto''', '''Tutorial''' or '''Guide''' is a ''documentation for accomplishing tasks''. If you wish to find a listing of all howtos on this wiki, look at the [[:Category:Guides|Category Guides]].<br />
<br />
Here is a selection:<br />
<br />
= Introducing Linux = <br />
* [[LinuxIntro]] - your starting point<br />
** [[Choose a Linux distribution]]<br />
** [[install Linux]]<br />
** [[open a console]]<br />
* [[Interoperability]]<br />
** [[Run Windows software]]<br />
** [[Share files with Windows]]<br />
** [[Install Windows fonts]]<br />
** [[Beginner's Command Line]] - migrating from windows to the linux command line<br />
<br />
= Disk and archive manipulation =<br />
* [[Clone a disk using dd]]<br />
* [[Configure storage devices]]<br />
* [[Create software RAID and volume groups]]<br />
* [[Embed a zip file into an image]]<br />
* [[Encrypt a disk]]<br />
* [[Make a USB disk bootable]]<br />
* [[Make backups]]<br />
* [[Pack and unpack files]]<br />
* [[Regshot for Linux]]<br />
* [[rsync with Google Drive]]<br />
<br />
= Setup and Office =<br />
* [[Creating startup scripts]]<br />
* Do [[Office tasks]] - word processing, spreadsheet, presentation, image manipulation and other<br />
* [[Install Software]]<br />
* [[Print]]<br />
* [[Scan]]<br />
* [[Schedule Tasks]]<br />
* [[Set up lm sensors]] - for monitoring CPU/Motherboard temperature, fan speeds, voltage information, etc.<br />
* [[Set up Gaming Mouse]] - slow down mouse pointer when using highly sensitive mice<br />
* [[Browsing tasks|Surf the web]] / [[Connect to the net]]<br />
<br />
= Fun Stuff =<br />
* [[Burn a CDROM]]<br />
* Play [[Games]]<br />
* Do [[Multimedia tasks]] - listen to music, extract CDs, watch videos and DVDs<br />
** [[Configure Sound]]<br />
** [[make your computer speak]]<br />
** [[Use Digital Cameras and Linux]]<br />
** [[Use Camcorders and Linux]]<br />
** [[Use Webcams and Linux]]<br />
** [[Watch tv]]<br />
** listen to [[webradIo]]<br />
* [[Talk to friends online]] - how to access common instant messaging networks, see also [[IM]].<br />
<br />
= System Administration =<br />
* [[Set up apache2 for https]]<br />
* [[Inplace upgrade from RHEL 5.x to RHEL 6.x]]<br />
* [[HOWTO Create ssh keys]]<br />
* [[HOWTO Create SSH Config file]]<br />
* [[How to install and configure SAMBA on Debian Squeeze]]<br />
* [[How to build and install your own Linux kernel]]<br />
* [[How to use Secure Boot with your own keys]]<br />
<br />
= See also =<br />
* [[TroubleShooting]] - you have a problem and need a solution<br />
* [[Tips & Tricks]] - you want new ideas</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Text_editor&diff=68479Text editor2021-02-13T15:32:41Z<p>Hazel: </p>
<hr />
<div>A '''text editor''' is an [[application]] that is used to write and edit plain text. It cannot be used for formatted text, for example text that contains varying fonts or font styles. For that you need a word processor.<br />
<br />
The following list categorizes editors by their ability to provide a comfortable [http://en.wikipedia.org/wiki/GUI gui] and also by their ability to process [[unicode]].<br />
<br />
= Specific applications =<br />
{| class="wikitable sortable" border=1<br />
! [[Application]] !! [[CLI]] or GUI !! [[Unicode]] support<br />
|-<br />
| [[ed]] || cli || ?<br />
|-<br />
| [[ex]] || cli || ?<br />
|-<br />
| [[emacs]] || both || yes<br />
|-<br />
| [[joe]] || cli || ?<br />
|-<br />
| [[yudit]] || gui || yes<br />
|-<br />
| [[Minimum Profit]] || cli || ?<br />
|-<br />
| [[nano]] || cli || ?<br />
|-<br />
| [[pico]] || cli || ?<br />
|-<br />
| [[vi]] and its derivatives || cli || ?<br />
|-<br />
| [http://bluefish.openoffice.nl/ bluefish] || gui || ?<br />
|-<br />
| [[jEdit]] || gui || ?<br />
|-<br />
| [[kate]] || gui || ? <br />
|-<br />
| [[kwrite]] || gui || ? <br />
|-<br />
| [[Gedit]] || gui || ? <br />
|-<br />
| [[gvim]] || gui || ? <br />
|-<br />
| [http://www.nedit.org/ NEdit] || gui || ?<br />
|}<br />
<br />
= See also =<br />
* [[Word Processor]]<br />
* [[WYSIWYG]]<br />
* [[Editor]]<br />
<br />
[[category:Editors]]<br />
[[Category:Application]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68478Partition2021-02-13T15:22:47Z<p>Hazel: /* Find out a partition's size */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If SCSI drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". A program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 letters of the alphabet. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, like Windows, can only be booted from a primary partition, Linux can be booted from either a primary or a logical partition.<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. Only [[mount|unmounted]] disks should be partitioned. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes, use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
Sizes expressed in bytes are often difficult to appreciate. Using fdisk -lh ''/dev/sdc1'' will give you the size in "humanly appropriate" units such as megabytes or gigabytes, depending on the size.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68477Partition2021-02-13T15:19:12Z<p>Hazel: /* How do I create partitions? */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If SCSI drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". A program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 letters of the alphabet. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, like Windows, can only be booted from a primary partition, Linux can be booted from either a primary or a logical partition.<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. Only [[mount|unmounted]] disks should be partitioned. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68476Partition2021-02-13T15:18:16Z<p>Hazel: /* Namespace */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If SCSI drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". A program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 letters of the alphabet. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, like Windows, can only be booted from a primary partition, Linux can be booted from either a primary or a logical partition.<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68475Partition2021-02-13T15:17:45Z<p>Hazel: /* Limitations */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If scsi drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". A program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 letters of the alphabet. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, like Windows, can only be booted from a primary partition, Linux can be booted from either a primary or a logical partition.<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68474Partition2021-02-13T15:15:49Z<p>Hazel: /* Namespace */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If scsi drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". A program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 alphabets. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, as e.g. Windows, can only be booted from a Primary partition, Linux can be booted from either a Primary or a Logical partition.<br />
<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68473Partition2021-02-13T15:15:13Z<p>Hazel: /* Namespace */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If scsi drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". To ensure consistent nomenclature, a program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 alphabets. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, as e.g. Windows, can only be booted from a Primary partition, Linux can be booted from either a Primary or a Logical partition.<br />
<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68472Partition2021-02-13T15:14:24Z<p>Hazel: /* Namespace */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Windows uses drive letters for all addressable partitions, starting from "C" (C,D,E,...).This is because "A" and "B" were originally used for floppy disks. Traditionally Linux referred to IDE hard drives according to their positions on the motherboard: the master and slave drives on the first controller were hda and hdb; those on the second controller were hdc and hdd. The 4 primary partitions were then referred to by numbers, for example hda1, hda2, hda3 and hda4. If there was an extended partition, the numbers of the logical partitions inside it always started with 5. If [[scsi]] drives were attached, they were referred to as sda, etc., the letters being assigned in the order in which the kernel detected the drives. <br />
<br />
Modern kernels no longer distinguish between these two types of drive but treat all hard drives as scsi. Consequently all modern drive designations start with "sd". To ensure consistent nomenclature, a program called [[udev]] communicates with the kernel and renames drives as they are detected according to stored rules, so that nomenclature is consistent over boots as it was under the traditional system. Because modern hard drives are quite large, there is now usually only a single hard drive in a computer and this will be called sda. If it is a DOS drive, its partitions will be numbered sda1 to sda4, with logical disks starting at sda5. If it is a GPT drive, all the partitions will be numbered continuously in the order in which they appear in the partition table.<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 alphabets. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, as e.g. Windows, can only be booted from a Primary partition, Linux can be booted from either a Primary or a Logical partition.<br />
<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68471Partition2021-02-13T14:58:53Z<p>Hazel: /* Types of partitions */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and therefore do not need to use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Linux reserves hda1, hda2, hda3 and hda4 for the 4 primary partitions and the first logical partition always starts with hda5. Windows counts through all addressable partitions by drive letters starting from "C" (C,D,E,...).<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 alphabets. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, as e.g. Windows, can only be booted from a Primary partition, Linux can be booted from either a Primary or a Logical partition.<br />
<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=Partition&diff=68470Partition2021-02-13T14:57:28Z<p>Hazel: /* Types of partitions */</p>
<hr />
<div>A '''partition''' is a logical section of a [[hard disk]] and a practical way for users to divide their disks up into parts that behave as independent, separate devices, which in reality reside on one hard disk. A partition is technically defined in the [[partition table]] of a hard disk.<br />
<br />
== Why partition? ==<br />
Partitioning has several advantages and disadvantages. <br />
<br />
=== Multiple-boot ===<br />
Most practically, partitioning allows you to set up different operating systems on a single disk. If you have successfully installed any multiple-boot system, say, with Linux, <br />
partitioning allows the different operating systems to coexist and not interfere.<br />
<br />
=== Managing hard disk space===<br />
Partitioning also alleviates the problem of managing hard disk space, especially within a multi-user system. For example, when a multi-user system is set up, the home directories and the system directories often reside on different partitions. Without partitioning the disk in this way, or without setting up adequate disk [[quota]] systems, a user can fill up the partition and render the system unusable. Separating respective directories by usage into partitions can assist in alleviating space issues.<br />
<br />
=== Problems with partitioning ===<br />
Partitioning a disk is a rather low-level operation, and if it fails, valuable data can get lost. Performing partitioning requires a high grade of technical proficiency and accuracy without the use of the right tools.<br />
<br />
== Partition Topology ==<br />
<br />
=== Types of partitions ===<br />
Traditional DOS/MBR disks contain three types of partitions: "Primary", "Extended" and "Logical" partitions. The basic types are '''Primary''' and '''Logical'''; '''Extended''' partitions are actually a special case of a Primary partition. A DOS disk can have a maximum of 4 primary partitions, of which one (but not more than than one) can be an extended partition. A number of logical partitions (also called "Logical Disks") can be defined within the extended partition, which acts purely as a container for them. Primary and logical partitions are addressable for disk space and can therefore contain data, whereas an extended partition has only a nominal entry in the partition table, representing the set of logical partitions which it contains.<br />
<br />
DOS and Windows make a distinction between primary and logical partitions. Only a primary partition can be booted, and consequently the Windows operating system must reside on a primary partition. Logical disks are used only for user data. Linux makes no such distinction, and Linux bootloaders such as [[GRUB]] will boot to any type of partition that can contain a [[filesystem]]. Another difference is that Windows requires the partition containing the OS to carry a special "boot" flag. Linux does not require this flag and Linux bootloaders ignore it.<br />
<br />
Modern GPT disks can have a considerable number of primary partitions and do not use extended partitions or logical disks at all.<br />
<br />
=== Namespace ===<br />
Linux reserves hda1, hda2, hda3 and hda4 for the 4 primary partitions and the first logical partition always starts with hda5. Windows counts through all addressable partitions by drive letters starting from "C" (C,D,E,...).<br />
<br />
=== Limitations ===<br />
In Windows the total number of partitions is limited by the 26 alphabets. Linux permits 63 partitions in an IDE disk but only 15 in an SCSI or Sata disk. Some operating system, as e.g. Windows, can only be booted from a Primary partition, Linux can be booted from either a Primary or a Logical partition.<br />
<br />
<br />
== Practical ==<br />
<br />
=== How do I create partitions? ===<br />
On [[Linux]] systems, partitions are managed by programs such as [[fdisk]] or [[cfdisk]]. It is very dangerous to repartition a running system, and any changes in partitioning can render the data on the affected areas of the disk unusable. You will almost never have to partition unless you are installing a new operating system, or a new hard drive.<br />
<br />
=== What partitions do I need? ===<br />
Read the [[Partitioning Guidelines]] for suggestions on how to divide up your available disk space.<br />
<br />
Older versions of [[LILO]] required that the boot information for the [[kernel]] reside on a partition near the &quot;front&quot; of the disk. Newer versions have eliminated this requirement.<br />
<br />
=== How do I see the partitions on my computer? ===<br />
You can look at the [[partition table]] of the [[device]] /dev/hda with:<br />
fdisk -l /dev/hda<br />
<br />
You can see all partitions (of all devices) known by the kernel with <br />
[[hwinfo]] --partition<br />
<br />
You can print the [[filesystem]] types in use with:<br />
df -hT<br />
<br />
=== Find out a partition's size ===<br />
To find out a partition's size in bytes (or megabytes or what may come in the future), use [[fdisk]]. Using fdisk on a partition will not print you a partition table, obviously, but it will print you the partition's size like this:<br />
fdisk -l ''/dev/sdc1''<br />
<br />
Disk /dev/sdc1: '''80.0 GB, 80023716864 bytes'''<br />
255 heads, 63 sectors/track, 9728 cylinders<br />
Units = cylinders of 16065 * 512 = 8225280 bytes<br />
Disk identifier: 0x00000000<br />
<br />
Device Boot Start End Blocks Id System<br />
In this example, we find out ''/dev/sdc1'' has a size of 80.0 GB.<br />
<br />
==See also==<br />
*[[cfdisk]]<br />
*[[cgdisk]]<br />
*[[fdisk]]<br />
*[[fixparts]]<br />
*[[gdisk]]<br />
*[[gparted]]<br />
*[[mkfs]]<br />
*[[lvm]]<br />
*[[ntfsprogs]]<br />
*[[parted]]<br />
*[[partprobe]]<br />
*[[partx]]<br />
*[[sfdisk]]<br />
*[[sgdisk]]<br />
*[[wipefs]]<br />
*[[Partition]]<br />
*[[GPT Partition]]<br />
*[[Partitioning]]<br />
*[[Partitioning guidelines]]<br />
<br />
<br />
[[Category:Filesystems]]</div>Hazelhttps://wiki.linuxquestions.org/index.php?title=AntiX&diff=68469AntiX2021-02-12T17:43:04Z<p>Hazel: </p>
<hr />
<div>'''AntiX''' is a Linux [[distribution]] of the [[Debian]] family which was created with older hardware in mind. Unlike Debian, it does not use [[systemd]] for initialisation. It runs well on limited memory and includes drivers for a number of old video cards. Both 64-bit and 32-bit versions are available.<br />
<br />
It emphasises small footprints and therefore does not support large [[desktop environments]] but instead uses a choice of [[window manager]]-based desktops including [[fluxbox]] and [[iceWM]]. For browsers, it provides the lightweight [http://www.dillo.org/ Dillo] and the graphical version of [[links]] as well as [[firefox]]. [[Libre Office|LibreOffice]] is available but is no longer included on installation images because of its size.<br />
<br />
AntiX uses the Debian package management system [[apt]] and the Debian repositories alongside its own repositories for AntiX-specific software and for systemd-free versions of standard software such as [[cups]].<br />
<br />
See also:<br />
https://antixlinux.com<br />
<br />
https://distrowatch.com/antix<br />
<br />
https://www.antixforum.com/forums</div>Hazel