Issue 11 - fix keyring name in Kernel Module Authentication
This commit is contained in:
parent
70cbe7e964
commit
0898221bc7
1 changed files with 32 additions and 32 deletions
|
|
@ -32,7 +32,7 @@ In order to use the kernel module utilities described in this chapter, first ens
|
|||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}dnf install kmod
|
||||
|
||||
|
||||
----
|
||||
|
||||
For more information on installing packages with DNF, see xref:../package-management/DNF.adoc#sec-Installing[Installing Packages].
|
||||
|
|
@ -48,33 +48,33 @@ You can list all kernel modules that are currently loaded into the kernel by run
|
|||
|
||||
~]$ lsmod
|
||||
Module Size Used by
|
||||
tcp_lp 12663 0
|
||||
bnep 19704 2
|
||||
tcp_lp 12663 0
|
||||
bnep 19704 2
|
||||
bluetooth 372662 7 bnep
|
||||
rfkill 26536 3 bluetooth
|
||||
fuse 87661 3
|
||||
ip6t_rpfilter 12546 1
|
||||
ip6t_REJECT 12939 2
|
||||
ipt_REJECT 12541 2
|
||||
xt_conntrack 12760 7
|
||||
ebtable_nat 12807 0
|
||||
ebtable_broute 12731 0
|
||||
fuse 87661 3
|
||||
ip6t_rpfilter 12546 1
|
||||
ip6t_REJECT 12939 2
|
||||
ipt_REJECT 12541 2
|
||||
xt_conntrack 12760 7
|
||||
ebtable_nat 12807 0
|
||||
ebtable_broute 12731 0
|
||||
bridge 110196 1 ebtable_broute
|
||||
stp 12976 1 bridge
|
||||
llc 14552 2 stp,bridge
|
||||
ebtable_filter 12827 0
|
||||
ebtable_filter 12827 0
|
||||
ebtables 30913 3 ebtable_broute,ebtable_nat,ebtable_filter
|
||||
ip6table_nat 13015 1
|
||||
nf_conntrack_ipv6 18738 5
|
||||
ip6table_nat 13015 1
|
||||
nf_conntrack_ipv6 18738 5
|
||||
nf_defrag_ipv6 34651 1 nf_conntrack_ipv6
|
||||
nf_nat_ipv6 13279 1 ip6table_nat
|
||||
ip6table_mangle 12700 1
|
||||
ip6table_security 12710 1
|
||||
ip6table_raw 12683 1
|
||||
ip6table_filter 12815 1
|
||||
ip6table_mangle 12700 1
|
||||
ip6table_security 12710 1
|
||||
ip6table_raw 12683 1
|
||||
ip6table_filter 12815 1
|
||||
ip6_tables 27025 5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw
|
||||
iptable_nat 13011 1
|
||||
nf_conntrack_ipv4 14862 4
|
||||
iptable_nat 13011 1
|
||||
nf_conntrack_ipv4 14862 4
|
||||
nf_defrag_ipv4 12729 1 nf_conntrack_ipv4
|
||||
nf_nat_ipv4 13263 1 iptable_nat
|
||||
nf_nat 21798 4 nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat
|
||||
|
|
@ -126,7 +126,7 @@ alias: pci:v00008086d00001502sv*sd*bc*sc*i*
|
|||
alias: pci:v00008086d0000105Esv*sd*bc*sc*i*
|
||||
depends: ptp
|
||||
intree: Y
|
||||
vermagic: 3.17.4-302.fc21.x86_64 SMP mod_unload
|
||||
vermagic: 3.17.4-302.fc21.x86_64 SMP mod_unload
|
||||
signer: Fedora kernel signing key
|
||||
sig_key: 1F:C9:E6:8F:74:19:55:63:48:FD:EE:2F:DE:B7:FF:9D:A6:33:7B:BF
|
||||
sig_hashalgo: sha256
|
||||
|
|
@ -202,7 +202,7 @@ To load a kernel module, run [command]#modprobe _module_name_pass:attributes[{bl
|
|||
|
||||
----
|
||||
~]# modprobe wacom
|
||||
|
||||
|
||||
----
|
||||
indexterm:[kernel module,directories,/lib/modules/kernel_version/kernel/drivers/]
|
||||
By default, [command]#modprobe# attempts to load the module from `/lib/modules/pass:attributes[{blank}]_kernel_version_pass:attributes[{blank}]/kernel/drivers/`. In this directory, each type of module has its own subdirectory, such as `net/` and `scsi/`, for network and SCSI interface drivers respectively.
|
||||
|
|
@ -219,9 +219,9 @@ You can load the `Fibre Channel over Ethernet` module verbosely by typing the fo
|
|||
|
||||
----
|
||||
~]# modprobe -v fcoe
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/scsi_transport_fc.ko.xz
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/libfc/libfc.ko.xz
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/fcoe/libfcoe.ko.xz
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/scsi_transport_fc.ko.xz
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/libfc/libfc.ko.xz
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/fcoe/libfcoe.ko.xz
|
||||
insmod /lib/modules/3.17.4-302.fc21.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko.xz
|
||||
----
|
||||
|
||||
|
|
@ -246,7 +246,7 @@ You can unload a kernel module by running [command]#modprobe -r _module_name_pas
|
|||
|
||||
----
|
||||
~]# modprobe -r wacom
|
||||
|
||||
|
||||
----
|
||||
|
||||
However, this command will fail if a process is using:
|
||||
|
|
@ -316,8 +316,8 @@ You can use [command]#modprobe# to load a kernel module with custom parameters u
|
|||
|
||||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}modprobe{nbsp}module_name{nbsp}parameter=value
|
||||
|
||||
~]#{nbsp}modprobe{nbsp}module_name{nbsp}parameter=value
|
||||
|
||||
----
|
||||
|
||||
====
|
||||
|
|
@ -355,7 +355,7 @@ Output would indicate that the module is already loaded into the kernel, in whic
|
|||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}modprobe e1000e InterruptThrottleRate=3000,3000,3000 debug=1
|
||||
|
||||
|
||||
----
|
||||
+
|
||||
This example illustrates passing multiple values to a single parameter by separating them with commas and omitting any spaces between them.
|
||||
|
|
@ -455,7 +455,7 @@ You can display information about the keys on the system key rings using the [co
|
|||
|
||||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}keyctl list %:.system_keyring
|
||||
~]#{nbsp}keyctl list %:.builtin_trusted_keys
|
||||
1 key in keyring:
|
||||
265061799: ---lswrv 0 0 asymmetric: Fedora kernel signing key: ba8e2919f98f3f8e2e27541cde0d1f...
|
||||
----
|
||||
|
|
@ -464,7 +464,7 @@ The following is abbreviated example output from a Fedora system where UEFI Secu
|
|||
|
||||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}keyctl list %:.system_keyring
|
||||
~]#{nbsp}keyctl list %:.builtin_trusted_keys
|
||||
5 keys in keyring:
|
||||
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c497...
|
||||
...asymmetric: Fedora kernel signing key: ba8e2919f98f3f8e2e27541cde0d...
|
||||
|
|
@ -625,7 +625,7 @@ Your kernel module is now ready for loading. Note that your signed kernel module
|
|||
|
||||
Once your public key is enrolled and is in the system keyring, the normal kernel module loading mechanisms will work transparently. In the following example, you will use [command]#mokutil# to add your public key to the MOK list and you will manually load your kernel module with [command]#modprobe#.
|
||||
|
||||
. Optionally, you can verify that your kernel module will not load before you have enrolled your public key. First, verify what keys have been added to the system key ring on the current boot by running the [command]#keyctl list %:.system_keyring# as root. Since your public key has not been enrolled yet, it should not be displayed in the output of the command.
|
||||
. Optionally, you can verify that your kernel module will not load before you have enrolled your public key. First, verify what keys have been added to the system key ring on the current boot by running the [command]#keyctl list %:.builtin_trusted_keys# as root. Since your public key has not been enrolled yet, it should not be displayed in the output of the command.
|
||||
|
||||
. Request enrollment of your public key.
|
||||
+
|
||||
|
|
@ -645,7 +645,7 @@ Once your public key is enrolled and is in the system keyring, the normal kernel
|
|||
+
|
||||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}keyctl list %:.system_keyring
|
||||
~]#{nbsp}keyctl list %:.builtin_trusted_keys
|
||||
----
|
||||
|
||||
. You should now be able to load your kernel module successfully.
|
||||
|
|
|
|||
Reference in a new issue