Wednesday, 16 October 2013

Recovering volume group metadata in LVM with UUID disk #CentOS_6_RHEL

Objective: Recover volume group metadata in LVM.

Environment: CentOS_6.3 (32-bit)

LVM version: 2.02.95

Brief introduction on LVM:

To use the device for an LVM logical volume the device must be initialized as a physical volume (PV), which on initializing places a label near the start of the device. By default, the LVM label is placed in the second 512-byte sector. The LVM label identifies the device as an LVM physical volume which contains the UUID for the physical name. It also stores the size of block devices in bytes, and LVM metadata stored on the disk.

The LVM metadata contains the configuration details of the LVM volume groups on your system. By default, an identical copy of the metadata is maintained in every metadata area in every physical volume within the volume group.

Error which I had received when accessing an disk, where metadata was corrupted.

# pvs -o pv_name,uuid
  Couldn't find device with uuid U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy.
- We would be able to find the UUID for the PV in /etc/lvm/archive directory, deactivating the volume and setting the partial(-P) argument will
enable you to find the UUID of the missing corrupted physical volume.

# vgchange -an --partial
  Partial mode. Incomplete logical volumes will be processed.
  Couldn't find device with uuid U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy.
  0 logical volume(s) in volume group "testvg" now active

# vgck testvg
  Couldn't find device with uuid U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy.
  The volume group is missing 1 physical volumes.

# pvck /dev/sdd
  Could not find LVM label on /dev/sdd

- pvcreate comes in handy restores the physical volume label with the metadata information contained in VG group(testvg). The restore file argument instructs the   pvcreate command to make the new physical volume compatible with the old one on the volume group, ensuring that the new metadata will not be placed where the old physical volume contained data.

NOTE: The pvcreate command overwrites only the LVM metadata areas and does not affect the existing data areas.

# pvcreate --uuid "U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy" --restore /etc/lvm/backup/testvg /dev/sdd
  Couldn't find device with uuid U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy.
  Writing physical volume data to disk "/dev/sdd"
  Physical volume "/dev/sdd" successfully created

- vgcfgrestore command to restore the volume group's metadata

# vgcfgrestore testvg
  Restored volume group testvg

# pvs -o pv_name,uuid | grep "U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy"
  /dev/sdd   U3qzRV-jakK-0JFC-zVmq-F1aa-nxrg-9JYsXy

Recovered volume metadata from LVM.

Thursday, 10 October 2013

Disk Encryption - eCryptfs & dm-crypt + LUKS - #CentOS_6/RHEL_6

Objective :- Disk encryption techniques.

Environment :- CentOS release 6.3(32-bit)

I would like to discuss few techniques available in linux for cryptographically protecting a logical part of a storage disk(folder, partition, whole disk, ...), so that all data that is written to it is automatically encrypted, and decrypted on-the-fly when read again.

Below two methods are discussed as below :-

1.  eCryptfs 
2.  dm-crypt with LUKS


I would describe the basic use of eCryptfs, which will guide through the process of creating a secure and a private directory which can store your sensitive and private data.

This doesn't require special on-disk storage allocation effort, such as seperate partition, you can mount eCryptfs on top of any single directory to protect it.All cryptographic metadata is stored in the headers of files, so encrypted data can be easily moved, stored for backup and recovered. 

There are few of the drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions, however instead you can combine it with dm-crypt. But in this article I would be combining dm-crypt with LUKS mechanism and demonstrate.

On summarizing, eCryptfs, a "pseudo-file system" which provides data and filename encryption on a per-file basis, it is a file system layer that resides on top of an actual file system,  providing encryption capabilities.

- Install the package.
#yum install ecryptfs-utils -y

Assume while creating a new file system(/db), I had created another file system layer that which resides on the top of the actual file system.
# df -h /db

Filesystem            Size  Used Avail Use% Mounted on
                      485M   11M  449M   3% /db

# mount -t ecryptfs /db /db  
Select key type to use for newly created files:
1) tspi
2) openssl
3) passphrase  
Selection: 3  
Select cipher:  
1) aes: blocksize = 16;min keysize = 16; max keysize = 32 (not loaded)  
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)  
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)  
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)  
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)  
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)  
Selection [aes]: 
Select key bytes:  
1) 16  
2) 32  
3) 24  
Selection [16]:  
Enable plaintext passthrough (y/n) [n]:  
Enable filename encryption (y/n) [n]:  
Attempting to mount with the following options:  
Mounted eCryptfs  
- Now there are two /db file system, one which is an actual file system, another which resides on the top of the file system.
# df -h | grep db
                      485M   11M  449M   3% /db
/db                   485M   11M  449M   3% /db

- Any thing written on the /db file system will now be encrypted.
:/db]# cat >encrypt_file
All files and directories will be encrypted in this file system.

- I would now unmount /db, which is encrypted file system. viewing the actual file system will result in garbled random looking characters.
Reading the encrypted sectors without permission will return garbled random-looking data instead of the actual files.
#umount /db 

:/db]# tail encrypt_file

fÓxpu;¬0éb¶EyºlH$ÖR/'úÚÿ±' £¢?ß¹[]v­*ã*Ʀ¡²Ò
Æéþ½ rll9æ½vÿså¢GÙMøåÇûÀÅë·ÙúKoí:/db]#

Hence we have successfully encrypted the files in the file system.

Snap is provided which is self-explanatory.

dm-crypt with LUKS

dm-crypt is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.

LUKS(Linux Unified Keystartup) is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.

Summarizing, LUKS is a standard format for device encryption. LUKS encrypts the parttion or volume, the volume must be decrypted before the file system in it can be mounted.

- Create a new partiton on the disk.

- Encrypt the new partition and set the decryption password.
# cryptsetup luksFormat /dev/sdd1

This will overwrite data on /dev/sdd1 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:

- You need to unlock the encrypted volume.
# cryptsetup luksOpen /dev/sdd1 cryptvg-cryptlv
Enter passphrase for /dev/sdd1:

- Create an ext4 file system on the decrypted volume.
[root@kickstart ~]# mkfs -t ext4 /dev/mapper/cryptvg-cryptlv

- Create a directory mount point and mount the file system.
# mount /dev/mapper/cryptvg-cryptlv /secret #

- When finished, unmount and lock the encrypted volume.
# umount /secret/

# cryptsetup luksClose /dev/mapper/cryptvg-cryptlv #

Persistant Mount Encrypted partition.

- Add your list of devices to be unlocked during the system startup.
# cat /etc/crypttab
Name         Device         /path/to/password
cryptvg-cryptlv /dev/sdd1       /root/encdisk

- Create an entry in fstab.
# tail -1 /etc/fstab
/dev/mapper/cryptvg-cryptlv     /secret         ext4    defaults        1 2

- Create a keyfile that includes the password. Make sure it is owned by the root and the mode is 600. Add the key for LKS.
#echo -n "passphrase" > /root/encdisk
#chown root /root/encdisk
#chmod 600 /root/encdisk
#cryptsetup luksAddKey /dev/sdd1 /root/encdisk

Reboot your system, it should not ask for any passphrase during the boot. Check your file system should be mounted automatically without providing the passphrase.

Providing the snap, which is self-explanatory.

NOTE: The device in the /etc/fstab and the /etc/crypttab should be the same. Since I made a mistake in these two files which made system to PANIC. This would be kernel was unable to boot with the name as in fstab.