#431 Added Wiki information disk-encryption-user-guide
Closed a year ago by copperi. Opened 2 years ago by mmccabe4.
fedora-docs/ mmccabe4/quick-docs master  into  main

@@ -28,5 +28,7 @@ 

  

  [NOTE]

  ====

- When systems run SELinux in permissive mode, users are able to label files incorrectly. Files created while SELinux is disabled are not labeled at all. This behavior causes problems when changing to enforcing mode because files are labeled incorrectly or are not labeled at all. To prevent incorrectly labeled and unlabeled files from causing problems, file systems are automatically relabeled when changing from the disabled state to permissive or enforcing mode.

+ When systems run SELinux in permissive mode, users and processes can label various file-system objects incorrectly. File-system objects created while SELinux is disabled are not labeled at all. This behavior causes problems when changing to enforcing mode because SELinux relies on correct labels of file-system objects. 

+ 

+ To prevent incorrectly labeled and unlabeled files from causing problems, file systems are automatically relabeled when changing from the disabled state to permissive or enforcing mode. In permissive mode, use the [command]`fixfiles -F onboot` command as root to create `/.autorelabel` file containing the `-F` option to ensure that files are relabeled upon next reboot.

  ====

@@ -5,22 +5,24 @@ 

  [#{context}-changing-to-enforcing-mode]

  = Changing to enforcing mode

  

- When SELinux is running in enforcing mode, it enforces the SELinux policy and denies access based on SELinux policy rules. In Fedora, enforcing mode is enabled by default when the system was initially installed with SELinux.

+ Use the following procedure to switch SELinux to enforcing mode. When SELinux is running in enforcing mode, it enforces the SELinux policy and denies access based on SELinux policy rules. In Fedora, enforcing mode is enabled by default when the system was initially installed with SELinux.

+ 

+ .Prerequisites

+ 

+ * The `selinux-policy-targeted`, `libselinux-utils`, and `policycoreutils` packages are installed on your system. 

+ 

+ * The `selinux=0` or `enforcing=0` kernel parameters are not used.

  

  .Procedure

  

- . Check the current SELinux mode by using the [command]`getenforce` command:

- +

- [subs="quotes"]

+ . Open the `/etc/selinux/config` file in a text editor of your choice, for example:

+ 

  ----

- $ *getenforce*

- Permissive

+ # vi /etc/selinux/config

  ----

- +

- If the command displays `Disabled`, then follow xref:{context}-enabling-selinux[]. If it displays `Permissive`, use the following steps to change mode to enforcing again:

  

- . Edit the `/etc/selinux/config` file as follows:

- +

+ . Configure the `SELINUX=enforcing` option:

+ 

  [subs="quotes"]

  ----

  # This file controls the state of SELinux on the system.
@@ -35,26 +37,43 @@ 

  SELINUXTYPE=targeted

  ----

  

- . Restart the system:

+ . Save the change, and restart the system:

  +

  [subs="quotes"]

  ----

- $ *reboot*

+ # reboot

  ----

  +

- On the next boot, SELinux relabels all files and directories in the system and adds the SELinux context for files and directories that were created when SELinux was disabled.

+ On the next boot, SELinux relabels all the files and directories within the system and adds SELinux context for files and directories that were created when SELinux was disabled.

+ 

+ .Verification

+ 

+ . After the system restarts, confirm that the `getenforce` command returns `Enforcing`:

+ 

+ ----

+ $ getenforce

+ Enforcing

+ ----

  

  [NOTE]

  ====

- After changing to enforcing mode, SELinux may deny some actions because of incorrect or missing SELinux policy rules. To view what actions SELinux denies:

+ After changing to enforcing mode, SELinux may deny some actions because of incorrect or missing SELinux policy rules. To view what actions SELinux denies, enter the following command as root:

  [subs="quotes"]

  ----

- $ *sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent*

+ # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today

  ----

- Alternatively, with the [package]`setroubleshoot-server` package installed:

+ Alternatively, with the [package]`setroubleshoot-server` package installed, enter:

  [subs="quotes"]

  ----

- $ *sudo sealert -a /var/log/audit/audit.log*

+ # grep "SELinux is preventing" /var/log/messages

  ----

+ 

+ Standard users can use the GUI `setroubleshoot` to file bugs directly to Bugzilla. 

+ 

+ If SELinux is active and the Audit daemon (auditd) is not running on your system, then search for certain SELinux messages in the output of the dmesg command:

+ ----

+ # dmesg | grep -i -e type=1300 -e type=1400

+ ----

+ 

  If SELinux denies some actions, see the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux[Troubleshooting problems related to SELinux] chapter in the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/index[RHEL 8 Using SELinux] document for information about troubleshooting.

  ====

@@ -5,14 +5,22 @@ 

  [#{context}-changing-to-permissive-mode]

  = Changing to permissive mode

  

- When SELinux is running in permissive mode, SELinux policy is not enforced. The system remains operational and SELinux does not deny any operations but only logs AVC messages, which can be then used for troubleshooting, debugging, and SELinux policy improvements. Each AVC is logged only once in this case.

+ Use the following procedure to permanently change SELinux mode to permissive. When SELinux is running in permissive mode, SELinux policy is not enforced. The system remains operational and SELinux does not deny any operations but only logs AVC messages, which can be then used for troubleshooting, debugging, and SELinux policy improvements. Each AVC is logged only once in this case. 

+ 

+ .Prerequisites 

+ 

+ * The `selinux-policy-targeted`, `libselinux-utils`, and `policycoreutils` packages are installed on your system.

+ * The `selinux=0` or `enforcing=0` kernel parameters are not used. 

  

  .Procedure

  

- To permanently change mode to permissive:

+ . Open the `/etc/selinux/config` file in a text editor of your choice, for example:

  

- . Edit the `/etc/selinux/config` file as follows:

- +

+ ----

+ # vi /etc/selinux/config

+ ----

+ 

+ . Configure the `SELINUX=permissive` option:

  [subs="quotes"]

  ----

  # This file controls the state of SELinux on the system.
@@ -31,5 +39,5 @@ 

  +

  [subs="quotes"]

  ----

- $ *reboot*

+ # *reboot*

  ----

@@ -5,13 +5,20 @@ 

  [#{context}-disabling-selinux]

  = Disabling SELinux

  

- When SELinux is disabled, SELinux policy is not loaded at all; it is not enforced and AVC messages are not logged. Therefore, all benefits of running SELinux listed in xref:{context}-benefits-of-selinux[Benefits of SELinux] are lost.

- 

+ Use the following procedure to permanently disable SELinux.

+  

  [IMPORTANT]

  ====

+ When SELinux is disabled, SELinux policy is not loaded at all; it is not enforced and AVC messages are not logged. Therefore, all benefits of running SELinux listed in xref:{context}-benefits-of-selinux[Benefits of SELinux] are lost.

+ 

  It is recommended to use permissive mode instead of permanently disabling SELinux. See xref:{context}-changing-to-permissive-mode[] for more information about permissive mode.

  ====

  

+ [Warning]

+ ====

+ Disabling SELinux using the SELINUX=disabled option in the /etc/selinux/config results in a process in which the kernel boots with SELinux enabled and switches to disabled mode later in the boot process. Because memory leaks and race conditions causing kernel panics can occur, prefer disabling SELinux by adding the selinux=0 parameter to the kernel command line as described in Changing SELinux modes at boot time if your scenario really requires to completely disable SELinux.

+ ====

+ 

  .Prerequisites

  

  * The [package]`grubby` package is installed:
@@ -24,23 +31,35 @@ 

  

  .Procedure

  

- To permanently disable SELinux:

- 

- . Configure your bootloader to add `selinux=0` to the kernel command line:

+ . Open the `/etc/selinux/config` file in a text editor of your choice, for example:

  +

  [subs="quotes"]

  ----

- $ *sudo grubby --update-kernel ALL --args selinux=0*

+ # vi /etc/selinux/config

  ----

  

- . Restart your system:

+ . Configure the SELINUX=disabled option:

  +

  [subs="quotes"]

  ----

- $ *reboot*

+ # This file controls the state of SELinux on the system.

+ # SELINUX= can take one of these three values:

+ #       enforcing - SELinux security policy is enforced.

+ #       permissive - SELinux prints warnings instead of enforcing.

+ #       disabled - No SELinux policy is loaded.

+ SELINUX=disabled

+ # SELINUXTYPE= can take one of these two values:

+ #       targeted - Targeted processes are protected,

+ #       mls - Multi Level Security protection.

+ SELINUXTYPE=targeted

+ ----

+ 

+ . Save the change, and restart your system:

+ ----

+ # reboot

  ----

  

- .Verification step

+ .Verification 

  

  * After reboot, confirm that the [command]`getenforce` command returns `Disabled`:

  +

@@ -7,7 +7,9 @@ 

  

  On boot, you can set several kernel parameters to change the way SELinux runs:

  

- enforcing=0::  Setting this parameter causes the machine to boot in permissive mode, which is useful when troubleshooting issues. Using permissive mode might be the only option to detect a problem if your file system is too corrupted. Moreover, in permissive mode the system continues to create the labels correctly. The AVC messages that are created in this mode can be different than in enforcing mode. In permissive mode, only the first denial is reported. However, in enforcing mode you might get a denial on reading a directory and an application stops. In permissive mode, you get the same AVC message, but the application continues reading files in the directory and you get an AVC for each denial in addition.

+ enforcing=0::  Setting this parameter causes the system to start in permissive mode, which is useful when troubleshooting issues. Using permissive mode might be the only option to detect a problem if your file system is too corrupted. Moreover, in permissive mode, the system continues to create the labels correctly. The AVC messages that are created in this mode can be different than in enforcing mode.

+ +

+ In permissive mode, only the first denial from a series of the same denials is reported. However, in enforcing mode, you might get a denial related to reading a directory, and an application stops. In permissive mode, you get the same AVC message, but the application continues reading files in the directory and you get an AVC for each denial in addition.

  

  selinux=0::  This parameter causes the kernel to not load any part of the SELinux infrastructure. The init scripts notice that the system booted with the [option]`selinux=0` parameter and touch the `/.autorelabel` file. This causes the system to automatically relabel the next time you boot with SELinux enabled.

  +
@@ -19,11 +21,11 @@ 

  autorelabel=1::  This parameter forces the system to relabel similarly to the following commands:

  +

  ----

- ~]# touch /.autorelabel

- ~]# reboot

+ # touch /.autorelabel

+ # reboot

  ----

  +

- If the system labeling contains a large amount of errors, you might need to boot in permissive mode in order that the autorelabel succeeds.

+ If a file system contains a large amount of mislabeled objects, start the system in permissive mode to make the autorelabel process successful.

  

  For additional SELinux-related kernel boot parameters, such as [option]`checkreqprot`, see the `kernel-parameters.txt` file. This file is available in the source package of your Linux kernel (.src.rpm). To download the source package containing the currently used kernel:

  ----

@@ -1,20 +1,245 @@ 

- ifdef::context[:parent-context: {context}]

- :context: luks

+ = Disk Encryption User Guide

+  

+ === Contents

+ . <<What is block device encryption?>>

+ . <<Encrypting block devices using dm-crypt/LUKS>>

+ .. <<Overview of LUKS>>

+ .. <<How will I access the encrypted devices after installation? (System Startup)>>

+ .. <<Choosing a Good Passphrase>>

+ . <<Creating Encrypted Block Devices in Anaconda>>

+ .. <<What Kinds of Block Devices Can Be Encrypted?>>

+ .. <<Limitations of Anaconda's Block Device Encryption Support>>

+ ... <<Filling the Device with Random Data Before Encrypting>>

+ ... <<Using a Key Comprised of Randomly Generated Data to Access Encrypted Devices>>

+ . <<Creating Encrypted Block Devices on the Installed System After Installation>>

+ .. <<Create the block devices>>

+ .. <<Optional: Fill the device with random data>>

+ .. <<Format the device as a dm-crypt/LUKS encrypted device>>

+ .. <<Create a mapping to allow access to the device's decrypted contents>>

+ .. <<Create filesystems on the mapped device, or continue to build complex storage structures using the mapped device>>

+ .. <<Add the mapping information to /etc/crypttab>>

+ .. <<Add an entry to /etc/fstab>>

+ . <<Common Post-Installation Tasks>>

+ .. <<Backup LUKS headers>>

+ .. <<Set a randomly generated key as an additional way to access an encrypted block device>>

+ ... <<Generate a key>>

+ ... <<Add the key to an available keyslot on the encrypted device>>

+ .. <<Add a new passphrase to an existing device>>

+ .. <<Remove a passphrase or key from a device>>

+  

+ === What is block device encryption?

+ Block device encryption encrypts/decrypts the data transparently as it is written/read from block devices, the underlying block device sees only encrypted data.

+  

+ To mount encrypted block devices the sysadmin (or user, depending on context) must provide a passphrase to activate the decryption key.

+  

+ Encryption provides additional security beyond existing OS security mechanisms in that it protects the device's contents even if it has been physically removed from the system. Some systems require the encryption key to be the same as for decryption, and other systems require a specific key for encryption and specific second key for enabling decryption.

+  

+ === Encrypting block devices using dm-crypt/LUKS

+ https://gitlab.com/cryptsetup/cryptsetup/[LUKS] (Linux Unified Key Setup) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy.

+  

+ LUKS uses the kernel device mapper subsystem via the `dm-crypt` module. This arrangement provides a low-level mapping that handles encryption and decryption of the device's data. User-level operations, such as creating and accessing encrypted devices, are accomplished through the use of the `cryptsetup` utility.

+  

+ ==== Overview of LUKS

+ * What LUKS does:

+ ** LUKS encrypts entire block devices

+ *** LUKS is thereby well-suited for protecting the contents of mobile devices such as:

+ **** Removable storage media

+ **** Laptop disk drives

+ ** The underlying contents of the encrypted block device are arbitrary.

+ *** This makes it useful for encrypting swap devices.

+ *** This can also be useful with certain databases that use specially formatted block devices for data storage.

+ ** LUKS uses the existing device mapper kernel subsystem.

+ *** This is the same subsystem used by LVM, so it is well tested.

+ ** LUKS provides passphrase strengthening.

+ *** This protects against dictionary attacks.

+ ** LUKS devices contain multiple key slots.

+ *** This allows users to add backup keys/passphrases.

+ * What LUKS does not do:

+ ** LUKS is not well-suited for applications requiring many (more than eight) users to have distinct access keys to the same device.

+ ** LUKS is not well-suited for applications requiring file-level encryption.

+  

+ ==== How will I access the encrypted devices after installation? (System Startup)

+ During system startup you will be presented with a passphrase prompt. After the correct passphrase has been provided the system will continue to boot normally. If you used different passphrases for multiple encrypted devices you may need to enter more than one passphrase during the startup.

+  

+ TIP: Consider using the same passphrase for all encrypted block devices within a given system. This will simplify system startup and you will have fewer passphrases to remember. Just make sure you choose a good passphrase!

+  

+ ==== Choosing a Good Passphrase

+ While dm-crypt/LUKS supports both keys and passphrases, the anaconda installer only supports the use of passphrases for creating and accessing encrypted block devices during installation.

+  

+ LUKS does provide passphrase strengthening but it is still a good idea to choose a good (meaning "difficult to guess") passphrase. Note the use of the term "passphrase", as opposed to the term "password". This is intentional. Providing a phrase containing multiple words to increase the security of your data is important.

+  

+ === Creating Encrypted Block Devices in Anaconda

+ You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions.

+  

+ To enable block device encryption, check the "Encrypt System" checkbox when selecting automatic partitioning or the "Encrypt" checkbox when creating an individual partition, software RAID array, or logical volume. After you finish partitioning, you will be prompted for an encryption passphrase. This passphrase will be required to access the encrypted devices. If you have pre-existing LUKS devices and provided correct passphrases for them earlier in the install process the passphrase entry dialog will also contain a checkbox. Checking this checkbox indicates that you would like the new passphrase to be added to an available slot in each of the pre-existing encrypted block devices.

+  

+ TIP: Checking the "Encrypt System" checkbox on the "Automatic Partitioning" screen and then choosing "Create custom layout" does not cause any block devices to be encrypted automatically.

  

- [id='encrypting-drives-using-luks']

- = Encrypting drives using LUKS

+ TIP: You can use `kickstart` to set a separate passphrase for each new encrypted block device.

+  

+ ==== What Kinds of Block Devices Can Be Encrypted?

+ Most types of block devices can be encrypted using LUKS. From anaconda you can encrypt partitions, LVM physical volumes, LVM logical volumes, and software RAID arrays.

+  

+ ==== Limitations of Anaconda's Block Device Encryption Support

+  

+ ===== Filling the Device with Random Data Before Encrypting

+ Filling a device with random data prior to encrypting improves the strength of the encryption. However, it can take a very long time to fill the device with random data. It is because of those time requirements that anaconda does not offer this option. This step can be performed manually, using a `kickstart %pre` script. Instructions can be found https://fedoraproject.org/wiki/Disk_Encryption_User_Guide#randomize_device[here].

+  

+ ===== Using a Key Comprised of Randomly Generated Data to Access Encrypted Devices

+ In addition to passphrases, LUKS devices can be accessed with a key comprised of randomly generated data. Setting up one or more keys to access the encrypted devices can be done on the installed system or through the use of a `kickstart %post` script. Instructions can be found https://fedoraproject.org/wiki/Disk_Encryption_User_Guide#new_key[here].

+  

+ === Creating Encrypted Block Devices on the Installed System After Installation

+ Encrypted block devices can be created and configured after installation.

+  

+ ==== Create the block devices

+ Create the block devices you want to encrypt by using `parted`, `pvcreate`, `lvcreate` and `mdadm`.

+  

+ ==== Optional: Fill the device with random data

+ Filling <device> (eg: `/dev/sda3`) with random data before encrypting it greatly increases the strength of the encryption. The downside is that it can take a very long time.

+  

+ WARNING: The commands below will destroy any existing data on the device.

+  

+ * The best way, which provides high quality random data but takes a long time (several minutes per gigabyte on most systems)

+ ----

+ dd if=/dev/urandom of=<device>

+ ----

+ * Fastest way, which provides lower quality random data

+ ----

+ badblocks -c 10240 -s -w -t random -v <device>

+ ----

+  

+ ==== Format the device as a dm-crypt/LUKS encrypted device

+  

+ WARNING: The commands below will destroy any existing data on the device.

+  

+ ----

+ cryptsetup luksFormat <device>

+ ----

+  

+ TIP: For more information, read the `cryptsetup(8)` man page.

+  

+ After supplying the passphrase twice the device will be formatted for use. To verify, use the following command:

+  

+ ----

+ cryptsetup isLuks <device> && echo Success

+ ----

+  

+ To see a summary of the encryption information for the device, use the following command:

+  

+ ----

+ cryptsetup luksDump <device>

+ ----

+  

+ ==== Create a mapping to allow access to the device's decrypted contents

+ To access the device's decrypted contents, a mapping must be established using the kernel `device-mapper`.

+  

+ It is useful to choose a meaningful name for this mapping. LUKS provides a UUID (Universally Unique Identifier) for each device. This, unlike the device name (eg: `/dev/sda3`), is guaranteed to remain constant as long as the LUKS header remains intact. To find a LUKS device's UUID, run the following command:

+  

+ ----

+ cryptsetup luksUUID <device>

+ ----

+  

+ An example of a reliable, informative and unique mapping name would be `luks-<uuid>`, where <uuid> is replaced with the device's LUKS UUID (eg: `luks-50ec957a-5b5a-47ee-85e6-f8085bbc97a8`). This naming convention might seem unwieldy but is it not necessary to type it often.

+  

+ ----

+ cryptsetup luksOpen <device> <name>

+ ----

+  

+ There should now be a device node, `/dev/mapper/<name>`, which represents the decrypted device. This block device can be read from and written to like any other unencrypted block device.

+  

+ To see some information about the mapped device, use the following command:

+  

+ ----

+ dmsetup info <name>

+ ----

+  

+ TIP: For more information, read the `dmsetup(8)` man page.

+  

+ ==== Create filesystems on the mapped device, or continue to build complex storage structures using the mapped device

+ Use the mapped device node (`/dev/mapper/<name>`) as any other block device. To create an `ext2` filesystem on the mapped device, use the following command:

+  

+ ----

+ mke2fs /dev/mapper/<name>

+ ----

+  

+ To mount this filesystem on `/mnt/test`, use the following command:

+  

+ IMPORTANT: The directory `/mnt/test` must exist before executing this command.

+  

+ ----

+ mount /dev/mapper/<name> /mnt/test

+ ----

+  

+ ==== Add the mapping information to /etc/crypttab

+  

+ In order for the system to set up a mapping for the device, an entry must be present in the `/etc/crypttab` file. If the file doesn't exist, create it and change the owner and group to root (`root:root`) and change the mode to `0744`. Add a line to the file with the following format:

+  

+ ----

+ <name>  <device>  none

+ ----

+  

+ The <device> field should be given in the form "UUID=<luks_uuid>", where <luks_uuid> is the LUKS uuid as given by the command `cryptsetup luksUUID <device>`. This ensures the correct device will be identified and used even if the device node (eg: `/dev/sda5`) changes.

+  

+ TIP: For details on the format of the `/etc/crypttab` file, read the `crypttab(5)` man page.

+  

+ ==== Add an entry to `/etc/fstab`

+ Add an entry to `/etc/fstab` file. This is only necessary if you want to establish a persistent association between the device and a mountpoint. Use the decrypted device, `/dev/mapper/<name>` in the `/etc/fstab` file.

+  

+ In many cases it is desirable to list devices in `/etc/fstab` by UUID or by a filesystem label. The main purpose of this is to provide a constant identifier in the event that the device name (eg: `/dev/sda4`) changes. LUKS device names in the form of `/dev/mapper/luks-<luks_uuid>` are based only on the device's LUKS UUID, and are therefore guaranteed to remain constant. This fact makes them suitable for use in `/etc/fstab`.

+  

+ TIP: For details on the format of the /etc/fstab file, read the fstab(5) man page.

+  

+ === Common Post-Installation Tasks

+  

+ ==== Backup LUKS headers

+ If the sectors containing the LUKS headers are damaged - by user error or HW failure - all data in the encrypted block device is lost. Backing up the headers can help recovering data in such cases.

+  

+ To backup the LUKS headers, use the following command:

+  

+ ----

+ cryptsetup luksHeaderBackup --header-backup-file <file> <device>

+ ----

+  

+ To restore the LUKS headers, use the following command:

+  

+ WARNING: The command below can destroy data, if wrong headers are applied or wrong device is selected! Be sure to backup headers from recovering device first.

+  

+ ----

+ cryptsetup luksHeaderRestore --header-backup-file <file> <device>

+ ----

+  

+ See also https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery

+  

+ ==== Set a randomly generated key as an additional way to access an encrypted block device

+  

+ ===== Generate a key

+  

+ This will generate a 256-bit key in the file `$HOME/keyfile`.

+  

+ ----

+ dd if=/dev/urandom of=$HOME/keyfile bs=32 count=1

+ chmod 600 $HOME/keyfile

+ ----

+  

+ ===== Add the key to an available keyslot on the encrypted device

+  

+ ----

+ cryptsetup luksAddKey <device> ~/keyfile

+ ----

+  

+ ===== Add a new passphrase to an existing device

+  

+ ----

+ cryptsetup luksAddKey <device>

+ ----

+  

+ After being prompted for any one of the existing passprases for authentication, you will be prompted to enter the new passphrase.

+  

+ ==== Remove a passphrase or key from a device

+  

+ ----

+ cryptsetup luksRemoveKey <device>

+ ----

+  

+ You will be prompted for the passphrase you wish to remove and then for any one of the remaining passphrases for authentication.

  

- As a system administrator, you can encrypt a block device. This section gives a brief introduction to block encryption, describes Linux Unified Key Setup (LUKS), and lists the steps to create an encrypted block device.

- 

- :leveloffset: +1

- 

- include::{partialsdir}/con_block-device-encryption.adoc[]

- 

- include::{partialsdir}/con_introduction-to-luks.adoc[]

- 

- include::{partialsdir}/creating-encrypted-block-devices.adoc[]

- 

- :leveloffset: 0

- 

- ifdef::parent-context[:context: {parent-context}]

- ifndef::parent-context[:!context:]

@@ -1,72 +1,306 @@ 

- ifdef::context[:parent-context: {context}]

- :context: prod_troubleshooting_selinux

+ = Troubleshooting problems related to SELinux

+ :toc:

  

- [id='prod_troubleshooting_selinux']

- = Troubleshooting SELinux

+ If you plan to enable SELinux on systems where it has been previously disabled or if you run a service in a non-standard configuration, you might need to troubleshoot situations potentially blocked by SELinux. Note that in most cases, SELinux denials are signs of misconfiguration.

  

- This document covers the basics of troubleshooting SELinux.

+ == Identifying SELinux denials

  

- SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Denial messages are logged when SELinux denies access. For example, an SELinux error generated by the Apache web server may appear as `comm="/usr/sbin/httpd"`.

+ Follow only the necessary steps from this procedure; in most cases, you need to perform just step 1.

  

- Each error message includes information on the source context (`scontext`) of that part of your system performing an action, and the target context (`tcontext`), the target of the action. In many cases, the source is a binary and the target a file.

+ *Procedure*

  

- == Understanding Denials

- When SELinux prevents any software from accessing a particular resource, for example, when *Firefox* is denied access to `/etc/shadow`, it generates a message and logs it in `/var/log/audit/audit.log` or `/var/log/messages` if *audit* service is disabled. If the log contains `avc: denied` that means it is an SELinux policy denial. Note that you would need administrator privileges (root access) on your system to be able to read this log file. An example denial would look like:

- -----

- type=AVC msg=audit(1214965667.121:635): avc:  denied  { unix_read unix_write } for  pid=15524 comm="npviewer.bin"

- key=59918130 scontext=unconfined_u:unconfined_r:nsplugin_t:s0-s0:c0.c1023

- tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s

- -----

- == Using the setroubleshoot utility

+ . When your scenario is blocked by SELinux, the [command]`/var/log/audit/audit.log` file is the first place to check for more information about a denial. To query Audit logs, use the `ausearch` tool. Because the SELinux decisions, such as allowing or disallowing access, are cached and this cache is known as the Access Vector Cache (AVC), use the `AVC` and `USER_AVC` values for the message type parameter, for example:

+ +

+ ----

+ # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

+ ----

+ +

+ If there are no matches, check if the Audit daemon is running. If it does not, repeat the denied scenario after you start auditd and check the Audit log again.

  

- *setroubleshoot* is a utility that parses the messages from SELinux and provides comprehensive help on what it means and possible actions to take. It has both a graphical utility for your desktop and a server side component that can send email alerts. It is installed by default on Fedora. To install it on your system, use the *Software* tool in GUI or enter the following command:

- -----

- $ sudo dnf install setroubleshoot

- -----

+ . In case auditd is running, but there are no matches in the output of ausearch, check messages provided by the systemd Journal:

+ +

+ ----

+ # journalctl -t setroubleshoot

+ ----

  

- To start the program, run the following command:

- -----

- $ sealert

- -----

+ . If SELinux is active and the Audit daemon is not running on your system, then search for certain SELinux messages in the output of the dmesg command:

+ +

+ ----

+ # dmesg | grep -i -e type=1300 -e type=1400

+ ----

  

- You can find recent alerts in the browser that appears.

+ . Even after the previous three checks, it is still possible that you have not found anything. In this case, AVC denials can be silenced because of `dontaudit` rules.

+ +

+ To temporarily disable `dontaudit` rules, allowing all denials to be logged:

+ +

+ ----

+ # semodule -DB

+ ----

+ +

+ After re-running your denied scenario and finding denial messages using the previous steps, the following command enables `dontaudit` rules in the policy again:

+ +

+ ----

+ # semodule -B

+ ----

  

- To troubleshoot an error, click the *troubleshoot* button in the SELinux Alert browser. The browser will return available options for resolving the error and commands to run to fix the problem.

+ . If you apply all four previous steps, and the problem still remains unidentified, consider if SELinux really blocks your scenario:

+ * Switch to permissive mode:

+ + 

+ ----

+ # setenforce 0

+ $ getenforce

+ Permissive

+ ----

+ * Repeat your scenario.

  

- [NOTE]

- ====

- Some troubleshooting events can be resolved by enabling a boolean switch policy. This will allow the activity to procede in the future, regardless of SELinux enforcing policy. It is not recommended to utilize booleans without fully understanding the issue. For more information on booleans, see the link:https://docs-old.fedoraproject.org/en-US/Fedora/25/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Working_with_SELinux-Booleans.html[Booleans] chapter in the SELinux User's and Administrator's Guide.

- ====

+ If the problem still occurs, something different than SELinux is blocking your scenario.

  

+ == Analyzing SELinux denial messages

  

- ////

- include::modules/con-troubleshooting-selinux-overview.adoc[leveloffset=+1]

+ After identifying that SELinux is blocking your scenario, you might need to analyze the root cause before you choose a fix.

  

- include::modules/con-troubleshooting-selinux-access-is-denied.adoc[leveloffset=+2]

+ *Prerequisites*

  

- include::modules/con_troubleshooting_selinux_top_three_causes_of_problems.adoc[leveloffset=+1]

+ ** The `policycoreutils-python-utils` and `setroubleshoot-server` packages are installed on your system.

  

- include::modules/con_troubleshooting_selinux_fixing_problems.adoc[leveloffset=+1]

+ *Procedure*

  

- include::modules/con_troubleshooting_selinux_searching_viewing_denials.adoc[leveloffset=+2]

+ . List more details about a logged denial using the `sealert` command, for example:

+ +

+ ----

+ $ sealert -l "*"

+ SELinux is preventing /usr/bin/passwd from write access on the file

+ /root/test.

  

- include::modules/con_troubleshooting_selinux_disabling_permissive_domains.adoc[leveloffset=+2]

+ *****  Plugin leaks (86.2 confidence) suggests *****************************

  

- include::modules/con_troubleshooting_selinux_raw_audit_messages.adoc[leveloffset=+1]

+ If you want to ignore passwd trying to write access the test file,

+ because you believe it should not need this access.

+ Then you should report this as a bug.

+ You can generate a local policy module to dontaudit this access.

+ Do

+ # ausearch -x /usr/bin/passwd --raw | audit2allow -D -M my-passwd

+ # semodule -X 300 -i my-passwd.pp

  

- include::modules/con_troubleshooting_selinux_sealert_messages.adoc[leveloffset=+2]

+ *****  Plugin catchall (14.7 confidence) suggests **************************

  

- include::modules/con_troubleshooting_selinux_allowing_access_audit.adoc[leveloffset=+1]

+ ...

  

- include::modules/proc_troubleshooting_selinux_allowing_access_audit.adoc[leveloffset=+2]

- ////

+ Raw Audit Messages

+ type=AVC msg=audit(1553609555.619:127): avc:  denied  { write } for

+ pid=4097 comm="passwd" path="/root/test" dev="dm-0" ino=17142697

+ scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023

+ tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

  

- == Additional Resources

+ ..

  

-  * link:https://docs-old.fedoraproject.org/en-US/Fedora/25/html/SELinux_Users_and_Administrators_Guide/chap-Security-Enhanced_Linux-Troubleshooting.html[Troubleshooting] in the SELinux User's and Administrator's Guide

+ Hash: passwd,passwd_t,admin_home_t,file,write

+ ----

  

-  * link:https://fedorapeople.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf[Four Key Causes of SELinux Errors]

+ . If the output obtained in the previous step does not contain clear suggestions:

  

+ * Enable full-path auditing to see full paths to accessed objects and to make additional Linux Audit event fields visible:

+ +

+ ----

+ # auditctl -w /etc/shadow -p w -k shadow-write

+ ----

  

- ifdef::parent-context[:context: {parent-context}]

- ifndef::parent-context[:!context:]

+ * Clear the `setroubleshoot` cache:

+ +

+ ----

+ # rm -f /var/lib/setroubleshoot/setroubleshoot.xml

+ ----

+ 

+ * Reproduce the problem.

+ * Repeat step 1.

+ +

+ After you finish the process, disable full-path auditing:

+ +

+ ----

+ # auditctl -W /etc/shadow -p w -k shadow-write

+ ----

+ 

+ . If `sealert` returns only `catchall` suggestions or suggests adding a new rule using the `audit2allow` tool, match your problem with examples listed and explained in SELinux denials in the Audit log.

+ 

+ *Additional resources*

+ 

+ * `sealert(8)` man page

+ 

+ == Fixing analyzed SELinux denials

+ 

+ In most cases, suggestions provided by the `sealert` tool give you the right guidance about how to fix problems related to the SELinux policy. See Analyzing SELinux denial messages for information how to use `sealert` to analyze SELinux denials.

+ 

+ Be careful when the tool suggests using the `audit2allow` tool for configuration changes. You should not use `audit2allow` to generate a local policy module as your first option when you see an SELinux denial. Troubleshooting should start with a check if there is a labeling problem. The second most often case is that you have changed a process configuration, and you forgot to tell SELinux about it.

+ 

+ **Labeling problems**

+ 

+ A common cause of labeling problems is when a non-standard directory is used for a service. For example, instead of using `/var/www/html/` for a website, an administrator might want to use `/srv/myweb/`. On Red Hat Enterprise Linux, the `/srv` directory is labeled with the `var_t` type. Files and directories created in /srv inherit this type. Also, newly-created objects in top-level directories, such as `/myserver`, can be labeled with the `default_t` type. SELinux prevents the Apache HTTP Server (`httpd`) from accessing both of these types. To allow access, SELinux must know that the files in `/srv/myweb/` are to be accessible by `httpd`:

+ 

+ ----

+ # semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"

+ ----

+ 

+ This `semanage` command adds the context for the `/srv/myweb/` directory and all files and directories under it to the SELinux file-context configuration. The `semanage` utility does not change the context. As root, use the `restorecon` utility to apply the changes:

+ 

+ ----

+ # restorecon -R -v /srv/myweb

+ ----

+ 

+ **Incorrect Context**

+ The `matchpathcon` utility checks the context of a file path and compares it to the default label for that path. The following example demonstrates the use of `matchpathcon` on a directory that contains incorrectly labeled files:

+ 

+ ----

+ $ matchpathcon -V /var/www/html/*

+ /var/www/html/index.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0

+ /var/www/html/page1.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0

+ ----

+ 

+ In this example, the `index.html` and `page1.html` files are labeled with the `user_home_t` type. This type is used for files in user home directories. Using the `mv` command to move files from your home directory may result in files being labeled with the `user_home_t` type. This type should not exist outside of home directories. Use the `restorecon` utility to restore such files to their correct type:

+ 

+ ----

+ # restorecon -v /var/www/html/index.html

+ restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0

+ ----

+ 

+ To restore the context for all files under a directory, use the `-R` option:

+ 

+ ----

+ # restorecon -R -v /var/www/html/

+ restorecon reset /var/www/html/page1.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0

+ restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0

+ ----

+ 

+ **Confined applications configured in non-standard ways**

+ 

+ Services can be run in a variety of ways. To account for that, you need to specify how you run your services. You can achieve this through SELinux booleans that allow parts of SELinux policy to be changed at runtime. This enables changes, such as allowing services access to NFS volumes, without reloading or recompiling SELinux policy. Also, running services on non-default port numbers requires policy configuration to be updated using the `semanage` command.

+ 

+ For example, to allow the Apache HTTP Server to communicate with MariaDB, enable the `httpd_can_network_connect_db` boolean:

+ 

+ ----

+ # setsebool -P httpd_can_network_connect_db on

+ ----

+ 

+ Note that the `-P` option makes the setting persistent across reboots of the system.

+ 

+ If access is denied for a particular service, use the `getsebool` and `grep` utilities to see if any booleans are available to allow access. For example, use the `getsebool -a | grep ftp` command to search for FTP related booleans:

+ 

+ ----

+ $ getsebool -a | grep ftp

+ ftpd_anon_write --> off

+ ftpd_full_access --> off

+ ftpd_use_cifs --> off

+ ftpd_use_nfs --> off

+ 

+ ftpd_connect_db --> off

+ httpd_enable_ftp_server --> off

+ tftp_anon_write --> off

+ ----

+ 

+ To get a list of booleans and to find out if they are enabled or disabled, use the `getsebool -a` command. To get a list of booleans including their meaning, and to find out if they are enabled or disabled, install the `selinux-policy-devel` package and use the `semanage boolean -l` command as root.

+ 

+ **Port numbers*

+ 

+ Depending on policy configuration, services can only be allowed to run on certain port numbers. Attempting to change the port a service runs on without changing policy may result in the service failing to start. For example, run the `semanage port -l | grep http` command as root to list `http` related ports:

+ 

+ ----

+ # semanage port -l | grep http

+ http_cache_port_t              tcp      3128, 8080, 8118

+ http_cache_port_t              udp      3130

+ http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443

+ pegasus_http_port_t            tcp      5988

+ pegasus_https_port_t           tcp      5989

+ ----

+ 

+ The `http_port_t` port type defines the ports Apache HTTP Server can listen on, which in this case, are TCP ports 80, 443, 488, 8008, 8009, and 8443. If an administrator configures `httpd.conf` so that httpd listens on port 9876 (`Listen 9876`), but policy is not updated to reflect this, the following command fails:

+ 

+ ----

+ # systemctl start httpd.service

+ Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.

+ 

+ # systemctl status httpd.service

+ httpd.service - The Apache HTTP Server

+    Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)

+    Active: failed (Result: exit-code) since Thu 2013-08-15 09:57:05 CEST; 59s ago

+   Process: 16874 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=0/SUCCESS)

+   Process: 16870 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)

+ ----

+ 

+ An SELinux denial message similar to the following is logged to `/var/log/audit/audit.log`:

+ 

+ ----

+ type=AVC msg=audit(1225948455.061:294): avc:  denied  { name_bind } for  pid=4997 comm="httpd" src=9876 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

+ ----

+ 

+ To allow `httpd` to listen on a port that is not listed for the `http_port_t` port type, use the `semanage port` command to assign a different label to the port:

+ 

+ ----

+ # semanage port -a -t http_port_t -p tcp 9876

+ ----

+ 

+ The `-a `option adds a new record; the `-t` option defines a type; and the -p option defines a protocol. The last argument is the port number to add.

+ 

+ **Corner cases, evolving or broken applications, and compromised systems**

+ 

+ Applications may contain bugs, causing SELinux to deny access. Also, SELinux rules are evolving – SELinux may not have seen an application running in a certain way, possibly causing it to deny access, even though the application is working as expected. For example, if a new version of PostgreSQL is released, it may perform actions the current policy does not account for, causing access to be denied, even though access should be allowed.

+ 

+ For these situations, after access is denied, use the `audit2allow` utility to create a custom policy module to allow access. You can report missing rules in the SELinux policy in Red Hat Bugzilla. For `Red Hat Enterprise Linux 8`, create bugs against the Red Hat Enterprise Linux 8 product, and select the `selinux-policy` component. Include the output of the `audit2allow -w -a` and `audit2allow -a` commands in such bug reports.

+ 

+ If an application asks for major security privileges, it could be a signal that the application is compromised. Use intrusion detection tools to inspect such suspicious behavior.

+ 

+ The Solution Engine on the Red Hat Customer Portal can also provide guidance in the form of an article containing a possible solution for the same or very similar problem you have. Select the relevant product and version and use SELinux-related keywords, such as selinux or avc, together with the name of your blocked service or application, for example: `selinux samba`.

+ 

+ == SELinux denials in the audit log

+ 

+ The Linux Audit system stores log entries in the `/var/log/audit/audit.log` file by default.

+ 

+ To list only SELinux-related records, use the `ausearch` command with the message type parameter set to `AVC` and `AVC_USER` at a minimum, for example:

+ 

+ ----

+ # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR

+ ----

+ 

+ An SELinux denial entry in the Audit log file can look as follows:

+ 

+ ----

+ type=AVC msg=audit(1395177286.929:1638): avc:  denied  { read } for  pid=6591 comm="httpd" name="webpages" dev="0:37" ino=2112 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir

+ ----

+ 

+ The most important parts of this entry are:

+ 

+ * `avc: denied` - the action performed by SELinux and recorded in Access Vector Cache (AVC)

+ * `{ read }` - the denied action

+ * `pid=6591` - the process identifier of the subject that tried to perform the denied action

+ * `comm="httpd"` - the name of the command that was used to invoke the analyzed process

+ * `httpd_t` - the SELinux type of the process

+ * `nfs_t` - the SELinux type of the object affected by the process action

+ * `tclass=dir` - the target object class

+ 

+ The previous log entry can be translated to:

+ 

+ __SELinux__ denied the `__httpd__` process with PID 6591 and the `__httpd_t__` type to read from a directory with the `__nfs_t__` type.

+ 

+ The following SELinux denial message occurs when the Apache HTTP Server attempts to access a directory labeled with a type for the Samba suite:

+ 

+ ----

+ type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for  pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

+ ----

+ 

+ * `{ getattr }` - the `getattr` entry indicates the source process was trying to read the target file’s status information. This occurs before reading files. SELinux denies this action because the process accesses the file and it does not have an appropriate label. Commonly seen permissions include `getattr`, `read`, and `write`.

+ * `path="/var/www/html/file1"` - the path to the object (target) the process attempted to access.

+ * `scontext="unconfined_u:system_r:httpd_t:s0"` - the SELinux context of the process (source) that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running with the `httpd_t` type.

+ * `tcontext="unconfined_u:object_r:samba_share_t:s0"` - the SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of `file1`.

+ 

+ This SELinux denial can be translated to:

+ 

+ SELinux denied the `__httpd__` process with PID 2465 to access the `__/var/www/html/file1__` file with the `__samba_share_t__` type, which is not accessible to processes running in the httpd_t domain unless configured otherwise.

+ 

+ **Additional resources**

+ 

+ * `auditd(8)` and `ausearch(8)` man pages

+ 

+ == Additional resources

+ 

+ * Basic SELinux Troubleshooting in CLI

+ * What is SELinux trying to tell me? The 4 key causes of SELinux errors

+ * link:https://docs-old.fedoraproject.org/en-US/Fedora/25/html/SELinux_Users_and_Administrators_Guide/chap-Security-Enhanced_Linux-Troubleshooting.html[Troubleshooting] in the SELinux User's and Administrator's Guide

+ * link:https://fedorapeople.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf[Four Key Causes of SELinux Errors]

Deleted LUKS encryption page for disk-encryption-user-guide.

I think we should use a different branch for this @mmccabe4 because otherwise merging this will also merge the changes in #423 and vice versa.

So, ideally, we don't work on master, we create a new branch and work on that. That way your master branch remains pristine.

So, first update we master branch from the main repo. We add it as a new "remote", and then pull from it to update it:

git remote add upstream https://pagure.io/fedora-docs/quick-docs.git
git checkout master
git pull upstream master

Now that our master branch is in sync with the main repo, we branch off it and work there:

git checkout -b luks-encryption-guide master

then we work and push your branches etc. and create the PR etc.

Looks like im still have trouble using GIT to push this document. I have
tried the guide written by Ben a few times but im not having luck. Did you
have any other help you could offer here?

On Fri, Mar 11, 2022 at 3:32 AM Ankur Sinha pagure@pagure.io wrote:

ankursinha commented on the pull-request: Added Wiki information disk-encryption-user-guide that you are following:
``
I think we should use a different branch for this @mmccabe4 because
otherwise merging this will also merge the changes in #423 and vice versa.

So, ideally, we don't work on master, we create a new branch and work on
that. That way your master branch remains pristine.

So, first update we master branch from the main repo. We add it as a new
"remote", and then pull from it to update it:

git remote add upstream https://pagure.io/fedora-docs/quick-docs.git git checkout master git pull upstream master

Now that our master branch is in sync with the main repo, we branch off
it and work there:
git checkout -b luks-encryption-guide master

then we work and push your branches etc. and create the PR etc.
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-docs/quick-docs/pull-request/431

What error are you running into? Could you drop by in the chat channels
sometime (matrix/irc) maybe and folks can help debug this there?

I am specifically having authentication error 401 on the push to my fork. I
have also had the error trying to do the same on the GitHub desktop app. Is
there an additional authentication step I am missing?

On Wed, Mar 23, 2022 at 3:03 AM Ankur Sinha pagure@pagure.io wrote:

ankursinha commented on the pull-request: Added Wiki information disk-encryption-user-guide that you are following:
``
What error are you running into? Could you drop by in the chat channels
sometime (matrix/irc) maybe and folks can help debug this there?

``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-docs/quick-docs/pull-request/431

So a 401 is an authentication error, which means it doesn't like the credentials you are presenting. If you're using https, you need to make sure you're using the correct username for different services because your username/password on GitHub may not be the same as what you use on GitLab/Pagure/Bitbucket

There's information on the web on how to correctly set up your username password for each service. For eg:

https://stackoverflow.com/questions/10054318/how-do-i-provide-a-username-and-password-when-running-git-clone-gitremote-git

Hello, it has been a while, but I am trying this task again. I no longer
get the 401 error. I started over and followed
https://docs.fedoraproject.org/en-US/fedora-docs/contributing/git/ to the
exact detail. Now on my final push I am getting git@pagure.io: Permission
denied (publickey).

I see you answered a question similar to this about a year ago, but it does
not look applicable to contributing to quick-docs.

On Mon, Mar 28, 2022 at 4:00 AM Ankur Sinha pagure@pagure.io wrote:

ankursinha commented on the pull-request: Added Wiki information disk-encryption-user-guide that you are following:
``
So a 401 is an authentication error, which means it doesn't like the
credentials you are presenting. If you're using https, you need to make
sure you're using the correct username for different services because your
username/password on GitHub may not be the same as what you use on
GitLab/Pagure/Bitbucket

There's information on the web on how to correctly set up your username
password for each service. For eg:

https://stackoverflow.com/questions/10054318/how-do-i-provide-a-username-and-password-when-running-git-clone-gitremote-git
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-docs/quick-docs/pull-request/431

This usually points to some trouble with the ssh key part.

So:

I have the SSH and have mine uploaded to pagure. This is on the windows
command prompt, is that my issue in locating the .ssh location?

On Wed, Apr 27, 2022 at 5:25 AM Ankur Sinha pagure@pagure.io wrote:

ankursinha commented on the pull-request: Added Wiki information disk-encryption-user-guide that you are following:
``
This usually points to some trouble with the ssh key part.

So:

``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-docs/quick-docs/pull-request/431

Possibly---unfortunately I haven't used git on Windows in ages, so I can't really say. I see a number of "howtos" on setting up Git with SSH on windows, maybe they're worth a look?

1 new commit added

  • Update modules/ROOT/pages/troubleshooting_selinux.adoc
2 years ago

rebased onto 8b0b9e4

a year ago

Pull-Request has been closed by copperi

a year ago