[securityguide] VPN: Mention other VPN types and move all IPSec info to IPSec section.
by Eric Christensen
commit 8f6a8c7ffb1257ceea6897a937833a1da484b706
Author: Nikos Mavrogiannopoulos <nmav(a)redhat.com>
Date: Mon Jun 16 15:00:35 2014 +0200
VPN: Mention other VPN types and move all IPSec info to IPSec section.
Signed-off-by: Eric H Christensen <sparks(a)redhat.com>
en-US/VPN.xml | 57 ++++++++++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 48 insertions(+), 9 deletions(-)
---
diff --git a/en-US/VPN.xml b/en-US/VPN.xml
index 42e9c99..f4a2242 100644
--- a/en-US/VPN.xml
+++ b/en-US/VPN.xml
@@ -11,21 +11,47 @@
To address this need, <firstterm>Virtual Private Networks</firstterm> (<abbrev>VPN</abbrev>s) were developed. Following the same functional principles as dedicated circuits, <abbrev>VPN</abbrev>s allow for secured digital communication between two parties (or networks), creating a <firstterm>Wide Area Network</firstterm> (<acronym>WAN</acronym>) from existing <firstterm>Local Area Networks</firstterm> (<acronym>LAN</acronym>s). Where it differs from frame relay or ATM is in its transport medium. <abbrev>VPN</abbrev>s transmit over IP using datagrams as the transport layer, making it a secure conduit through the Internet to an intended destination. Most free software <abbrev>VPN</abbrev> implementations incorporate open standard encryption methods to further mask data in transit.
</para>
<para>
- Some organizations employ hardware <abbrev>VPN</abbrev> solutions to augment security, while others use software or protocol-based implementations. Several vendors provide hardware <abbrev>VPN</abbrev> solutions, such as Cisco, Nortel, IBM, and Checkpoint. There is a free software-based <abbrev>VPN</abbrev> solution for Linux called FreeS/Wan that utilizes a standardized <firstterm>Internet Protocol Security</firstterm> (<abbrev>IPsec</abbrev>) implementation. These <abbrev>VPN</abbrev> solutions, irrespective of whether they are hardware or software based, act as specialized routers that exist between the IP connection from one office to another.
+ Some organizations employ hardware <abbrev>VPN</abbrev> solutions to augment security, while others use software or protocol-based implementations. Several vendors provide hardware <abbrev>VPN</abbrev> solutions, such as Cisco, Nortel, IBM, and Checkpoint. There are many free software-based <abbrev>VPN</abbrev> solutions for Linux, such as OpenVPN, OpenConnect, FreeS/Wan and others.
+ They differ on the secure communication protocol used for channel establishment and
+ features.
</para>
- <section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-How_Does_a_VPN_Work">
- <title>How Does a VPN Work?</title>
+ <section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-Which_VPN_types">
+ <title>Which types of VPN exist?</title>
<para>
- When a packet is transmitted from a client, it sends it through the <abbrev>VPN</abbrev> router or gateway, which adds an <firstterm>Authentication Header</firstterm> (<abbrev>AH</abbrev>) for routing and authentication. The data is then encrypted and, finally, enclosed with an <firstterm>Encapsulating Security Payload</firstterm> (<abbrev>ESP</abbrev>). This latter constitutes the decryption and handling instructions.
+ There are different types of VPN protocols, depending on the
+ underlying secure communication protocols used. In the following
+ paragraphs we try to enumerate the available solutions.
</para>
<para>
- The receiving <abbrev>VPN</abbrev> router strips the header information, decrypts the data, and routes it to its intended destination (either a workstation or other node on a network). Using a network-to-network connection, the receiving node on the local network receives the packets already decrypted and ready for processing. The encryption/decryption process in a network-to-network <abbrev>VPN</abbrev> connection is transparent to a local node.
- </para>
- <para>
- With such a heightened level of security, an attacker must not only intercept a packet, but decrypt the packet as well. Intruders who employ a man-in-the-middle attack between a server and client must also have access to at least one of the private keys for authenticating sessions. Because they employ several layers of authentication and encryption, <abbrev>VPN</abbrev>s are a secure and effective means of connecting multiple remote nodes to act as a unified intranet.
+ <itemizedlist>
+ <listitem>
+ <para>
+ <acronym>IPSec</acronym> VPNs that utilize the standardized <firstterm>Internet Protocol Security</firstterm>. Typically the implementation lies in the kernel-space.
+ </para>
+ <para>
+ FreeS/Wan is of this VPN type.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <acronym>SSL/TLS</acronym> VPNs that utilize the standardized <firstterm>Transport Layer Security</firstterm> protocol or the <firstterm>Datagram Transport Layer Security Protocol</firstterm> (DTLS). Typically the implementation lies on user-space.
+ </para>
+ <para>
+ OpenConnect is of this VPN type.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Custom VPN protocols.
+ </para>
+ <para>
+ OpenVPN is such a protocol that has its key exchange based on SSL.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
</section>
-
+
<section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-VPNs_and_PROD">
<title>VPNs and &PRODUCT;</title>
<para>
@@ -41,6 +67,19 @@
<para>
The <abbrev>IPsec</abbrev> implementation in &PRODUCT; uses <firstterm>Internet Key Exchange</firstterm> (<firstterm>IKE</firstterm>), a protocol implemented by the Internet Engineering Task Force (<acronym>IETF</acronym>), used for mutual authentication and secure associations between connecting systems.
</para>
+
+ <section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-How_Does_an_IPSec_VPN_Work">
+ <title>How Does an IPSec VPN Work?</title>
+ <para>
+ When a packet is transmitted from a client, it sends it through the <abbrev>VPN</abbrev> router or gateway, which adds an <firstterm>Authentication Header</firstterm> (<abbrev>AH</abbrev>) for routing and authentication. The data is then encrypted and, finally, enclosed with an <firstterm>Encapsulating Security Payload</firstterm> (<abbrev>ESP</abbrev>). This latter constitutes the decryption and handling instructions.
+ </para>
+ <para>
+ The receiving <abbrev>VPN</abbrev> router strips the header information, decrypts the data, and routes it to its intended destination (either a workstation or other node on a network). Using a network-to-network connection, the receiving node on the local network receives the packets already decrypted and ready for processing. The encryption/decryption process in a network-to-network <abbrev>VPN</abbrev> connection is transparent to a local node.
+ </para>
+ <para>
+ With such a heightened level of security, an attacker must not only intercept a packet, but decrypt the packet as well. Intruders who employ a man-in-the-middle attack between a server and client must also have access to at least one of the private keys for authenticating sessions. Because they employ several layers of authentication and encryption, <abbrev>VPN</abbrev>s are a secure and effective means of connecting multiple remote nodes to act as a unified intranet.
+ </para>
+ </section>
<section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-Creating_an_IPsec_Connection">
<title>Creating an <abbrev>IPsec</abbrev> Connection</title>
9 years, 10 months
[securityguide] Changed some wording around the IPSec portion of the VPN section.
by Eric Christensen
commit 193f1e699ca32d9ca33bbed4e0de0cda95b5e196
Author: Eric H Christensen <sparks(a)redhat.com>
Date: Wed Jun 11 16:04:10 2014 -0400
Changed some wording around the IPSec portion of the VPN section.
en-US/VPN.xml | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/en-US/VPN.xml b/en-US/VPN.xml
index 1cf796a..42e9c99 100644
--- a/en-US/VPN.xml
+++ b/en-US/VPN.xml
@@ -29,7 +29,7 @@
<section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-VPNs_and_PROD">
<title>VPNs and &PRODUCT;</title>
<para>
- &PRODUCT; provides various options in terms of implementing a software solution to securely connect to a <acronym>WAN</acronym>. <firstterm>Internet Protocol Security</firstterm> (<acronym>IPsec</acronym>) is the supported <abbrev>VPN</abbrev> implementation for &PRODUCT;, and sufficiently addresses the usability needs of organizations with branch offices or remote users.
+ &PRODUCT; provides various options in terms of implementing a software solution to securely communicating across a <acronym>WAN</acronym>. One option available within &PRODUCT; is <firstterm>Internet Protocol Security</firstterm> (<acronym>IPsec</acronym>) which does a good job of addressing the usability needs of many organizations. Another option is <firstterm>OpenVPN</firstterm> which has functionality built into GNOME's Network Manager.
</para>
</section>
@@ -41,7 +41,6 @@
<para>
The <abbrev>IPsec</abbrev> implementation in &PRODUCT; uses <firstterm>Internet Key Exchange</firstterm> (<firstterm>IKE</firstterm>), a protocol implemented by the Internet Engineering Task Force (<acronym>IETF</acronym>), used for mutual authentication and secure associations between connecting systems.
</para>
- </section>
<section id="sect-Security_Guide-Virtual_Private_Networks_VPNs-Creating_an_IPsec_Connection">
<title>Creating an <abbrev>IPsec</abbrev> Connection</title>
@@ -945,6 +944,7 @@ include "/etc/racoon/<replaceable>X.X.X.X</replaceable>.conf"</screen>
</para>
<screen>[root@myServer ~] # /sbin/ifdown <replaceable><nickname></replaceable></screen>
</section>
+ </section>
</section>
9 years, 10 months
[securityguide] Added LUKS instructions from the Install Guide.
by Eric Christensen
commit e1fbfaf06227e0363a421579dd0831a489ffc8e0
Author: Eric H Christensen <sparks(a)redhat.com>
Date: Wed Jun 11 07:17:46 2014 -0400
Added LUKS instructions from the Install Guide.
en-US/DiskEncryptionUserGuide.xml | 789 +++++++++++++++++++++++++------------
en-US/Encryption.xml | 2 +-
2 files changed, 533 insertions(+), 258 deletions(-)
---
diff --git a/en-US/DiskEncryptionUserGuide.xml b/en-US/DiskEncryptionUserGuide.xml
index 19bbf3a..50d28f4 100644
--- a/en-US/DiskEncryptionUserGuide.xml
+++ b/en-US/DiskEncryptionUserGuide.xml
@@ -1,280 +1,555 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
-
-<chapter id="Disk_Encryption_Guide">
- <title>Disk Encryption Guide</title>
- <section>
- <title>What is block device encryption? </title>
- <para> Block device encryption protects the data on a block device by encrypting it. To access the device's decrypted contents, a user must provide a passphrase or key as authentication. This 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.</para>
- </section>
- <section>
- <title>Encrypting block devices using dm-crypt/LUKS </title>
- <para>
- <ulink url="http://luks.endorphin.org"> LUKS</ulink> (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.</para>
- <para>LUKS uses the kernel device mapper subsystem via the <command>dm-crypt</command> 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 <command>cryptsetup</command> utility.
- </para>
- <section>
- <title>Overview of LUKS </title>
- <itemizedlist>
- <listitem>
- <para>What LUKS does:
- <itemizedlist>
- <listitem>
- <para>LUKS encrypts entire block devices
- <itemizedlist>
- <listitem>
- <para>LUKS is thereby well-suited for protecting the contents of mobile devices such as:
- <itemizedlist>
- <listitem>
- <para>Removable storage media</para>
- </listitem>
- <listitem>
- <para>Laptop disk drives</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- <listitem>
- <para>The underlying contents of the encrypted block device are arbitrary.
- <itemizedlist>
- <listitem>
- <para>This makes it useful for encrypting <command>swap</command> devices.</para>
- </listitem>
- <listitem>
- <para>This can also be useful with certain databases that use specially formatted block devices for data storage.</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- <listitem>
- <para>LUKS uses the existing device mapper kernel subsystem.
- <itemizedlist>
- <listitem>
- <para>This is the same subsystem used by LVM, so it is well tested.</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- <listitem>
- <para>LUKS provides passphrase strengthening.
- <itemizedlist>
- <listitem>
- <para>This protects against dictionary attacks.</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- <listitem>
- <para>LUKS devices contain multiple key slots.
- <itemizedlist>
- <listitem>
- <para>This allows users to add backup keys/passphrases.</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- <listitem>
- <para>What LUKS does <emphasis>not</emphasis> do:
- <itemizedlist>
- <listitem>
- <para>LUKS is not well-suited for applications requiring many (more than eight) users to have distinct access keys to the same device.</para>
- </listitem>
- <listitem>
- <para>LUKS is not well-suited for applications requiring file-level encryption.</para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </itemizedlist>
- </section>
- <section>
- <title>How will I access the encrypted devices after installation? (System Startup) </title>
- <para> 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.</para>
- <para>
- <note><title>Tip</title>
- <para>Consider using the same passphrase for all encrypted block devices in a given system. This will simplify system startup and you will have fewer passphrases to remember. Just make sure you choose a good passphrase!</para>
- </note>
- </para>
- </section>
- <section>
- <title>Choosing a Good Passphrase </title>
- <para> 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.</para>
- <para>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.</para>
- </section>
- </section>
-
- <section>
- <title>Creating Encrypted Block Devices in Anaconda </title>
- <para> You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions.</para>
- <para>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.</para>
- <para>
- <note><title>Tip</title>
- <para>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.</para>
- </note>
- </para>
- <para>
- <note><title>Tip</title>
- <para>You can use <command>kickstart</command> to set a separate passphrase for each new encrypted block device.</para>
- </note>
- </para>
- <section>
- <title>What Kinds of Block Devices Can Be Encrypted? </title>
- <para> 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.</para>
- </section>
- <section>
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Security_Guide.ent">
+%BOOK_ENTITIES;
+]>
+<section id="sect-Security_Guide-Disk_Encryption_Guide">
+ <title>Disk Encryption</title>
+ <section>
+ <title>What is block device encryption? </title>
+ <para>
+ Block device encryption protects the data on a block device by encrypting it. To access the device's decrypted contents, a user must provide a passphrase or key as authentication. This 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.
+ </para>
+
+ </section>
+
+ <section>
+ <title>Encrypting block devices using dm-crypt/LUKS </title>
+ <para>
+ <firstterm>Linux Unified Key Setup</firstterm> (LUKS) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy.
+ </para>
+ <para>
+ LUKS uses the kernel device mapper subsystem via the <command>dm-crypt</command> 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 <command>cryptsetup</command> utility.
+ </para>
+ <section>
+ <title>Overview of LUKS </title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ What LUKS does:
+ <itemizedlist>
+ <listitem>
+ <para>
+ LUKS encrypts entire block devices
+ <itemizedlist>
+ <listitem>
+ <para>
+ LUKS is thereby well-suited for protecting the contents of mobile devices such as:
+ <itemizedlist>
+ <listitem>
+ <para>
+ Removable storage media
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Laptop disk drives
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The underlying contents of the encrypted block device are arbitrary.
+ <itemizedlist>
+ <listitem>
+ <para>
+ This makes it useful for encrypting <command>swap</command> devices.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ This can also be useful with certain databases that use specially formatted block devices for data storage.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ LUKS uses the existing device mapper kernel subsystem.
+ <itemizedlist>
+ <listitem>
+ <para>
+ This is the same subsystem used by LVM, so it is well tested.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ LUKS provides passphrase strengthening.
+ <itemizedlist>
+ <listitem>
+ <para>
+ This protects against dictionary attacks.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ LUKS devices contain multiple key slots.
+ <itemizedlist>
+ <listitem>
+ <para>
+ This allows users to add backup keys/passphrases.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ What LUKS does <emphasis>not</emphasis> do:
+ <itemizedlist>
+ <listitem>
+ <para>
+ LUKS is not well-suited for applications requiring many (more than eight) users to have distinct access keys to the same device.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ LUKS is not well-suited for applications requiring file-level encryption.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+ <para>
+ More detailed information about LUKS is available from the project website at <ulink url="http://code.google.com/p/cryptsetup/">http://code.google.com/p/cryptsetup/</ulink>.
+ </para>
+
+ </section>
+
+ <section>
+ <title>How will I access the encrypted devices after installation? (System Startup) </title>
+ <para>
+ 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.
+ </para>
+ <para>
+ <note>
+ <title>Tip</title>
+ <para>
+ Consider using the same passphrase for all encrypted block devices in a given system. This will simplify system startup and you will have fewer passphrases to remember. Just make sure you choose a good passphrase!
+ </para>
+
+ </note>
+
+ </para>
+
+ </section>
+
+ <section>
+ <title>Choosing a Good Passphrase </title>
+ <para>
+ 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.
+ </para>
+ <para>
+ 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.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section>
+ <title>Creating Encrypted Block Devices in Anaconda </title>
+ <para>
+ You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ <note>
+ <title>Tip</title>
+ <para>
+ 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.
+ </para>
+
+ </note>
+
+ </para>
+ <para>
+ <note>
+ <title>Tip</title>
+ <para>
+ You can use <command>kickstart</command> to set a separate passphrase for each new encrypted block device.
+ </para>
+
+ </note>
+
+ </para>
+ <section>
+ <title>What Kinds of Block Devices Can Be Encrypted? </title>
+ <para>
+ 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.
+ </para>
+
+ </section>
+
+ <!-- <section>
<title>Limitations of Anaconda's Block Device Encryption Support </title>
<para>This section is about Anaconda's Block Device Encryption Support</para>
- <!--section>
+ section>
<title>Filling the Device with Random Data Before Encrypting </title>
<para> 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 <command>kickstart %pre</command> script. Instructions can be found <xref linkend="randomize_device"/>.</para>
- </section-->
- <!--section>
+ </section>
+ section>
<title>Using a Key Comprised of Randomly Generated Data to Access Encrypted Devices </title>
<para> 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 <command>kickstart %post</command> script. Instructions can be found <xref linkend="new_key"/>.</para>
- </section-->
- </section>
- </section>
-
- <section>
- <title>Creating Encrypted Block Devices on the Installed System After Installation </title>
- <para> Encrypted block devices can be created and configured after installation. </para>
- <section>
- <title>Create the block devices </title>
- <para> Create the block devices you want to encrypt by using <command>parted</command>, <command>pvcreate</command>, <command>lvcreate</command> and <command>mdadm</command>.</para>
- </section>
- <section id="randomize_device">
- <title>Optional: Fill the device with random data</title>
- <para> Filling <device> (eg: <filename>/dev/sda3</filename>) with random data before encrypting it greatly increases the strength of the encryption. The downside is that it can take a very long time.</para>
- <para>
- <warning><title>Warning</title>
- <para>The commands below will destroy any existing data on the device.</para>
- </warning>
- </para>
- <itemizedlist>
- <listitem>
- <para> The best way, which provides high quality random data but takes a long time (several minutes per gigabyte on most systems):</para><programlisting>dd if=/dev/urandom of=<device></programlisting>
- </listitem>
- <listitem>
- <para> Fastest way, which provides lower quality random data:</para><programlisting>badblocks -c 10240 -s -w -t random -v <device></programlisting>
- </listitem>
- </itemizedlist>
- </section>
- <section>
- <title>Format the device as a dm-crypt/LUKS encrypted device </title>
- <para>
- <warning><title>Warning</title>
- <para>The command below will destroy any existing data on the device.</para>
- </warning>
-
- </para><programlisting>cryptsetup luksFormat <device></programlisting>
-
- <para>
- <note><title>Tip</title>
- <para>For more information, read the <command>cryptsetup(8)</command> man page.</para>
- </note>
- </para><para>After supplying the passphrase twice the device will be formatted for use. To verify, use the following command:</para>
- <programlisting>cryptsetup isLuks <device> && echo Success</programlisting>
- <para>To see a summary of the encryption information for the device, use the following command:</para>
- <programlisting>cryptsetup luksDump <device></programlisting>
</section>
- <section>
- <title>Create a mapping to allow access to the device's decrypted contents </title>
- <para> To access the device's decrypted contents, a mapping must be established using the kernel <command>device-mapper</command>.</para><para>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: <filename>/dev/sda3</filename>), is guaranteed to remain constant as long as the LUKS header remains intact. To find a LUKS device's UUID, run the following command:</para>
- <programlisting>cryptsetup luksUUID <device></programlisting>
+ </section> --> <section id="sect-Security_Guide-Disk_Encryption_Guide-Saving_Passphrases">
+ <title>Saving Passphrases</title>
+ <indexterm significance="normal">
+ <primary>Encryption</primary>
+ <secondary>Passphrases</secondary>
+ <tertiary>Saving passphrases</tertiary>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>Passphrases</primary>
+ <secondary>Block device encryption passphrases</secondary>
+ <tertiary>Saving block device encryption passphrases</tertiary>
+
+ </indexterm>
+ <para>
+ If you use a kickstart file during installation, you can automatically save the passphrases used during installation to an encrypted file (an <firstterm>escrow packet</firstterm>) on the local file system. To use this feature, you must have an X.509 certificate available at a location that <application>anaconda</application> can access. To specify the URL of this certificate, add the <parameter>--escrowcert</parameter> parameter to any of the <command>autopart</command>, <command>logvol</command>, <command>part</command> or <command>raid</command> commands. During installation, the encryption keys for the specified devices are saved in files in <filename>/root</filename>, encrypted with the certificate.
+ </para>
+ <para>
+ You can save escrow packets during installation only with the use of a kickstart file. You cannot save an escrow packet during an interactive installation, although you can create one on an installed system with the <application>volume_key</application> tool. The <application>volume_key</application> tool also allows you to use the information stored in an escrow packet to restore access to an encrypted volume. Refer to the <application>volume_key</application> manpage for more information.
+ </para>
+
+ </section>
- <para>An example of a reliable, informative and unique mapping name would be <command>luks-<uuid></command>, where <uuid> is replaced with the device's LUKS UUID (eg: <command>luks-50ec957a-5b5a-47ee-85e6-f8085bbc97a8</command>). This naming convention might seem unwieldy but is it not necessary to type it often.</para>
- <programlisting>cryptsetup luksOpen <device> <name></programlisting>
+ <section id="sect-Security_Guide-Disk_Encryption_Guide-Creating_and_Saving_Backup_Passphrases">
+ <title>Creating and Saving Backup Passphrases</title>
+ <indexterm significance="normal">
+ <primary>Encryption</primary>
+ <secondary>Backup passphrases</secondary>
+ <tertiary>Creating backup passphrases</tertiary>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>Encryption</primary>
+ <secondary>Backup passphrases</secondary>
+ <tertiary>Saving backup passphrases</tertiary>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>Passphrases</primary>
+ <secondary>Block device encryption passphrases</secondary>
+ <tertiary>Creating backup block device encryption passphrases</tertiary>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>Passphrases</primary>
+ <secondary>Block device encryption passphrases</secondary>
+ <tertiary>Saving backup block device encryption passphrases</tertiary>
+
+ </indexterm>
+ <para>
+ If you use a kickstart file during installation, <application>anaconda</application> can add a randomly generated backup passphrase to each block device on the system and save each passphrase to an encrypted file on the local file system. Specify the URL of this certificate with the <parameter>--escrowcert</parameter> parameter as described in <xref linkend="sect-Security_Guide-Disk_Encryption_Guide-Saving_Passphrases" />, followed by the <parameter>--backuppassphrase</parameter> parameter for each of the kickstart commands that relate to the devices for which you want to create backup passphrases.
+ </para>
+ <para>
+ Note that this feature is available only while performing a kickstart installation.
+ </para>
+
+ </section>
- <para>There should now be a device node, <filename>/dev/mapper/<name></filename>, which represents the decrypted device. This block device can be read from and written to like any other unencrypted block device.</para>
- <para>To see some information about the mapped device, use the following command:</para>
+
+ </section>
+
+ <section>
+ <title>Creating Encrypted Block Devices on the Installed System After Installation </title>
+ <para>
+ Encrypted block devices can be created and configured after installation, using either the following method or <application>Disk Utility</application>.
+ </para>
+ <section>
+ <title>Create the block devices </title>
+ <para>
+ Create the block devices you want to encrypt by using <command>parted</command>, <command>pvcreate</command>, <command>lvcreate</command> and <command>mdadm</command>.
+ </para>
+
+ </section>
- <programlisting>dmsetup info <name></programlisting>
+ <section id="randomize_device">
+ <title>Optional: Fill the device with random data</title>
+ <para>
+ Filling <device> (eg: <filename>/dev/sda3</filename>) with random data before encrypting it greatly increases the strength of the encryption. The downside is that it can take a very long time.
+ </para>
+ <para>
+ <warning>
+ <title>Warning</title>
+ <para>
+ The commands below will destroy any existing data on the device.
+ </para>
+
+ </warning>
+
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The best way, which provides high quality random data but takes a long time (several minutes per gigabyte on most systems):
+ </para>
+
+<programlisting>dd if=/dev/urandom of=<device></programlisting>
+
+ </listitem>
+ <listitem>
+ <para>
+ Fastest way, which provides lower quality random data:
+ </para>
+
+<programlisting>badblocks -c 10240 -s -w -t random -v <device></programlisting>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
- <para>
- <note><title>Tip</title>
- <para>For more information, read the <command>dmsetup(8)</command> man page.</para>
- </note>
- </para>
- </section>
- <section>
- <title>Create filesystems on the mapped device, or continue to build complex storage structures using the mapped device </title>
- <para> Use the mapped device node (<filename>/dev/mapper/<name></filename>) as any other block device. To create an <command>ext2</command> filesystem on the mapped device, use the following command:</para>
+ <section>
+ <title>Format the device as a dm-crypt/LUKS encrypted device </title>
+ <warning>
+ <title>Warning</title>
+ <para>
+ The command below will destroy any existing data on the device.
+ </para>
+
+ </warning>
+
+<programlisting>cryptsetup luksFormat <device></programlisting>
+ <para>
+ <note>
+ <para>
+ For more information, read the <command>cryptsetup(8)</command> man page.
+ </para>
+
+ </note>
+
+ </para>
+ <para>
+ After supplying the passphrase twice the device will be formatted for use. To verify, use the following command:
+ </para>
+
+<programlisting>cryptsetup isLuks <device> && echo Success</programlisting>
+ <para>
+ To see a summary of the encryption information for the device, use the following command:
+ </para>
+
+<programlisting>cryptsetup luksDump <device></programlisting>
+
+ </section>
- <programlisting>mke2fs /dev/mapper/<name></programlisting>
+ <section>
+ <title>Create a mapping to allow access to the device's decrypted contents </title>
+ <para>
+ To access the device's decrypted contents, a mapping must be established using the kernel <command>device-mapper</command>.
+ </para>
+ <para>
+ 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: <filename>/dev/sda3</filename>), is guaranteed to remain constant as long as the LUKS header remains intact. To find a LUKS device's UUID, run the following command:
+ </para>
+
+<programlisting>cryptsetup luksUUID <device></programlisting>
+ <para>
+ An example of a reliable, informative and unique mapping name would be <command>luks-<uuid></command>, where <uuid> is replaced with the device's LUKS UUID (eg: <command>luks-50ec957a-5b5a-47ee-85e6-f8085bbc97a8</command>). This naming convention might seem unwieldy but is it not necessary to type it often.
+ </para>
+
+<programlisting>cryptsetup luksOpen <device> <name></programlisting>
+ <para>
+ There should now be a device node, <filename>/dev/mapper/<name></filename>, which represents the decrypted device. This block device can be read from and written to like any other unencrypted block device.
+ </para>
+ <para>
+ To see some information about the mapped device, use the following command:
+ </para>
+
+<programlisting>dmsetup info <name></programlisting>
+ <para>
+ <note>
+ <title>Tip</title>
+ <para>
+ For more information, read the <command>dmsetup(8)</command> man page.
+ </para>
+
+ </note>
+
+ </para>
+
+ </section>
- <para>To mount this filesystem on <filename>/mnt/test</filename>, use the following command:</para>
- <para>
- <important>
- <para>The directory <filename>/mnt/test</filename> must exist before executing this command.</para>
- </important>
- </para>
- <programlisting>mount /dev/mapper/<name> /mnt/test</programlisting>
+ <section>
+ <title>Create filesystems on the mapped device, or continue to build complex storage structures using the mapped device </title>
+ <para>
+ Use the mapped device node (<filename>/dev/mapper/<name></filename>) as any other block device. To create an <command>ext2</command> filesystem on the mapped device, use the following command:
+ </para>
+
+<programlisting>mke2fs /dev/mapper/<name></programlisting>
+ <para>
+ To mount this filesystem on <filename>/mnt/test</filename>, use the following command:
+ </para>
+ <para>
+ <important>
+ <para>
+ The directory <filename>/mnt/test</filename> must exist before executing this command.
+ </para>
+
+ </important>
+
+ </para>
+
+<programlisting>mount /dev/mapper/<name> /mnt/test</programlisting>
+
+ </section>
- </section>
- <section>
- <title>Add the mapping information to <filename>/etc/crypttab</filename></title>
- <para> In order for the system to set up a mapping for the device, an entry must be present in the <filename>/etc/crypttab</filename> file. If the file doesn't exist, create it and change the owner and group to root (<command>root:root</command>) and change the mode to <command>0744</command>. Add a line to the file with the following format:</para>
+ <section>
+ <title>Add the mapping information to <filename>/etc/crypttab</filename></title>
+ <para>
+ In order for the system to set up a mapping for the device, an entry must be present in the <filename>/etc/crypttab</filename> file. If the file doesn't exist, create it and change the owner and group to root (<command>root:root</command>) and change the mode to <command>0744</command>. Add a line to the file with the following format:
+ </para>
+
+<programlisting><name> <device> none</programlisting>
+ <para>
+ The <device> field should be given in the form "UUID=<luks_uuid>", where <luks_uuid> is the LUKS uuid as given by the command <command>cryptsetup luksUUID <device></command>. This ensures the correct device will be identified and used even if the device node (eg: <filename>/dev/sda5</filename>) changes.
+ </para>
+ <para>
+ <note>
+ <title>Tip</title>
+ <para>
+ For details on the format of the <filename>/etc/crypttab</filename> file, read the <command>crypttab(5)</command> man page.
+ </para>
+
+ </note>
+
+ </para>
+
+ </section>
- <programlisting><name> <device> none</programlisting>
+ <section>
+ <title>Add an entry to <filename>/etc/fstab</filename></title>
+ <para>
+ Add an entry to /etc/fstab. This is only necessary if you want to establish a persistent association between the device and a mountpoint. Use the decrypted device, <filename>/dev/mapper/<name></filename> in the <filename>/etc/fstab</filename> file.
+ </para>
+ <para>
+ In many cases it is desirable to list devices in <filename>/etc/fstab</filename> 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: <filename>/dev/sda4</filename>) changes. LUKS device names in the form of <filename>/dev/mapper/luks-<luks_uuid></filename> are based only on the device's LUKS UUID, and are therefore guaranteed to remain constant. This fact makes them suitable for use in <filename>/etc/fstab</filename>.
+ </para>
+ <para>
+ <note>
+ <title>Title</title>
+ <para>
+ For details on the format of the <filename>/etc/fstab</filename> file, read the <command>fstab(5)</command> man page.
+ </para>
+
+ </note>
+
+ </para>
+
+ </section>
- <para>The <device> field should be given in the form "UUID=<luks_uuid>", where <luks_uuid> is the LUKS uuid as given by the command <command>cryptsetup luksUUID <device></command>. This ensures the correct device will be identified and used even if the device node (eg: <filename>/dev/sda5</filename>) changes.</para>
- <para>
- <note><title>Tip</title>
- <para>For details on the format of the <filename>/etc/crypttab</filename> file, read the <command>crypttab(5)</command> man page.</para>
- </note>
- </para>
+
</section>
- <section>
- <title>Add an entry to <filename>/etc/fstab</filename></title>
- <para> Add an entry to /etc/fstab. This is only necessary if you want to establish a persistent association between the device and a mountpoint. Use the decrypted device, <filename>/dev/mapper/<name></filename> in the <filename>/etc/fstab</filename> file.</para>
- <para>In many cases it is desirable to list devices in <filename>/etc/fstab</filename> 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: <filename>/dev/sda4</filename>) changes. LUKS device names in the form of <filename>/dev/mapper/luks-<luks_uuid></filename> are based only on the device's LUKS UUID, and are therefore guaranteed to remain constant. This fact makes them suitable for use in <filename>/etc/fstab</filename>.</para>
- <para>
- <note><title>Title</title>
- <para>For details on the format of the <filename>/etc/fstab</filename> file, read the <command>fstab(5)</command> man page.</para>
- </note>
+
+ <section>
+ <title>Common Post-Installation Tasks </title>
+ <para>
+ The following sections are about common post-installation tasks.
</para>
- </section>
- </section>
- <section>
- <title>Common Post-Installation Tasks </title>
- <para>The following sections are about common post-installation tasks.</para>
- <section id="new_key">
- <title>Set a randomly generated key as an additional way to access an encrypted block device</title>
- <para>These sections are about generating keys and adding keys.</para>
- <section>
- <title>Generate a key </title>
- <para> This will generate a 256-bit key in the file <filename>$HOME/keyfile</filename>.</para>
-
- <programlisting>
+ <section id="new_key">
+ <title>Set a randomly generated key as an additional way to access an encrypted block device</title>
+ <para>
+ These sections are about generating keys and adding keys.
+ </para>
+ <section>
+ <title>Generate a key </title>
+ <para>
+ This will generate a 256-bit key in the file <filename>$HOME/keyfile</filename>.
+ </para>
+
+<programlisting>
dd if=/dev/urandom of=$HOME/keyfile bs=32 count=1
chmod 600 $HOME/keyfile
- </programlisting>
+</programlisting>
+
</section>
- <section>
- <title>Add the key to an available keyslot on the encrypted device </title>
- <programlisting>cryptsetup luksAddKey <device> ~/keyfile</programlisting>
+
+ <section>
+ <title>Add the key to an available keyslot on the encrypted device </title>
+
+<programlisting>cryptsetup luksAddKey <device> ~/keyfile</programlisting>
+
</section>
-
- </section>
- <section>
- <title>Add a new passphrase to an existing device </title>
-
- <programlisting>cryptsetup luksAddKey <device></programlisting>
-
- <para>After being prompted for any one of the existing passphrases for authentication, you will be prompted to enter the new passphrase.</para>
- </section>
- <section>
- <title>Remove a passphrase or key from a device </title>
-
- <programlisting>cryptsetup luksRemoveKey <device></programlisting>
-
- <para>You will be prompted for the passphrase you wish to remove and then for any one of the remaining passphrases for authentication.</para>
- </section>
+
+
+ </section>
+
+ <section>
+ <title>Add a new passphrase to an existing device </title>
+
+<programlisting>cryptsetup luksAddKey <device></programlisting>
+ <para>
+ After being prompted for any one of the existing passphrases for authentication, you will be prompted to enter the new passphrase.
+ </para>
+
+ </section>
+
+ <section>
+ <title>Remove a passphrase or key from a device </title>
+
+<programlisting>cryptsetup luksRemoveKey <device></programlisting>
+ <para>
+ You will be prompted for the passphrase you wish to remove and then for any one of the remaining passphrases for authentication.
+ </para>
+
+ </section>
+
+ </section>
+
</section>
-</chapter>
+
diff --git a/en-US/Encryption.xml b/en-US/Encryption.xml
index cb8fa28..5df7691 100644
--- a/en-US/Encryption.xml
+++ b/en-US/Encryption.xml
@@ -64,7 +64,7 @@ AuthorizedKeysFile .ssh/authorized_keys</screen>The first line tells the SSH pro
<para>Similarly to passwords and any other authentication mechanism, you should change your <application>SSH</application> keys regularly. When you do make sure you clean out any unused key from the authorized_key file.</para>
</section>
</section>
- <xi:include href="LUKSDiskEncryption.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+ <xi:include href="DiskEncryptionUserGuide.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="7_Zip.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Using_GPG.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
</section>
9 years, 10 months
[install-guide/F20: 11/11] Merge branch 'master' into F20
by pbokoc
commit 089e67e2bee07b86596784ad13eb723b799c316b
Merge: 5268f43 92a2b3d
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Tue Jun 10 14:01:20 2014 +0200
Merge branch 'master' into F20
Conflicts:
quickstart.cfg
en-US/Installation_Guide.ent | 2 +-
en-US/Installation_Quick_Start_Guide.ent | 1 +
en-US/Package_Selection_common-note-3.xml | 2 +-
en-US/new-users.xml | 6 ++++++
publican.cfg | 2 +-
quickstart.cfg | 1 +
6 files changed, 11 insertions(+), 3 deletions(-)
---
9 years, 11 months
[install-guide/F20] (11 commits) ...Merge branch 'master' into F20
by pbokoc
Summary of changes:
39c5963... Removing unused files (*)
8bd211f... Clarification about routing in Network Configuration (*)
7c57961... Updating zanata.xml with the current locale map (*)
f78136e... Adding note on lack of 32bit UEFI support, BZ995128 (*)
88a04e9... add reference to sysadmin docs for yum usage, BZ1005479 (*)
9d6a07c... Fixing the quickstart.cfg config file (*)
b02ea46... Fixing a broken build (how did that happen?!) (*)
b2987eb... correcting version syntax for publican 4 (*)
405e56f... adding BZURL entity as required by publican-fedora-4.0-1 (*)
92a2b3d... Updating config files for building in Koji (*)
089e67e... Merge branch 'master' into F20
(*) This commit already existed in another branch; no separate mail sent
9 years, 11 months
[install-guide] Updating config files for building in Koji
by pbokoc
commit 92a2b3d798b71c0951751534d674573d6a4a7929
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Mon Jun 9 16:20:30 2014 +0200
Updating config files for building in Koji
publican.cfg | 2 +-
quickstart.cfg | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/publican.cfg b/publican.cfg
index dff532d..024e160 100644
--- a/publican.cfg
+++ b/publican.cfg
@@ -8,4 +8,4 @@ brand: fedora
#web_version_label: UNUSED
condition: install-guide
mainfile: Installation_Guide
-
+os_ver: .el6
diff --git a/quickstart.cfg b/quickstart.cfg
index 090cc07..719caf0 100644
--- a/quickstart.cfg
+++ b/quickstart.cfg
@@ -10,3 +10,4 @@ condition: quick-start
mainfile: Installation_Quick_Start_Guide
rev_file: Revision_History-quickstart.xml
type: Article
+os_ver: .el6
9 years, 11 months