Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
i want to do full disk encryption on a disk. here are some details:
1. the disk is /dev/sdc, not /dev/sda.
2. its passphrase will be entered manually.
3. i will be mounting it via the admin user (auto-logged-in, sudo authorized)
4. home directories for most users will be on it (not root or admin).
5. i may, some day, have container and/or virtual machine systems in some form on it.
6. there may be only one partition or there may be more than one.
7. it is intended to secure even the partition table and boot sector.
8. i may want to do other disks and memory sticks this way.
9. i want to use the simplest mechanism for encryption, even if it involves more work.
do i really need to use LVM, as every instruction page i have found online would have me do? to me, LVM is adding more work for the system to do. i am not counting the crypto that is being done as part of that work.
does anyone know of a non-LVM way to deploy full disk encryption that i will not be booting from? i am using Xubuntu 18.04.6 and later on 22.04 LTS (freshly installed onto a non-encrypted disk then upgraded as needed). there is no dual-booting on this system
The entire exercise should at least be educational. A LUKS (e.g) container is just a block device once its opened; feel free to construct a partition table therein. T'were it me, I would encrypt the entire device (without partitioning).
Good luck with your plans for /home.
tl;dr - use LVM, it has all the plumbing already tested.
I dunno what you mean, but personally I only ever used LUKS in recent times.
I partition my disks "normally" and manually create with cryptsetup etc or through some tools do it automatically (like distro installer). I've used this for partitions and full disks internal and external. Never had a problem.
right! but should i go with revolver or semi-auto?
Quote:
Originally Posted by syg00
The entire exercise should at least be educational. A LUKS (e.g) container is just a block device once its opened; feel free to construct a partition table therein. T'were it me, I would encrypt the entire device (without partitioning).
Good luck with your plans for /home.
tl;dr - use LVM, it has all the plumbing already tested.
the plan is to do full disk encryption to make a new full disk device appear. then partition that new device. I/O to all sectors would go through encryption or decryption. if the disk is stolen, the thieves would have no knowledge of how it's encrypted. i would enter the passphrase after it is booted up as part of adding the disk to the running system. then file system(s) can be mounted.
If you encrypt the entire device and then partition the encrypted container, you will have to add an extra step, probably a call to kpartx, in the init scripts to scan that container for partitions.
If you use LUKS, the header on the device will proudly proclaim that this is a LUKS container and tell the encryption parameters, other than the key of course. You could hide that identification by using LUKS with a detached header stored elsewhere, or else set up the encryption without LUKS. For the latter, you will have to specify any non-default encryption parameters (cipher specification, hash method, key size, etc.) each time the container is unlocked.
i want to do full disk encryption on a disk. here are some details:
1. the disk is /dev/sdc, not /dev/sda.
2. its passphrase will be entered manually.
3. i will be mounting it via the admin user (auto-logged-in, sudo authorized)
4. home directories for most users will be on it (not root or admin).
5. i may, some day, have container and/or virtual machine systems in some form on it.
6. there may be only one partition or there may be more than one.
7. it is intended to secure even the partition table and boot sector.
8. i may want to do other disks and memory sticks this way.
9. i want to use the simplest mechanism for encryption, even if it involves more work.
do i really need to use LVM, as every instruction page i have found online would have me do? to me, LVM is adding more work for the system to do. i am not counting the crypto that is being done as part of that work.
does anyone know of a non-LVM way to deploy full disk encryption that i will not be booting from? i am using Xubuntu 18.04.6 and later on 22.04 LTS (freshly installed onto a non-encrypted disk then upgraded as needed). there is no dual-booting on this system
This article outlines various scenarios, with - as far as I can see - full instructions.
Take your pick, make your choice.
If you encrypt the entire device and then partition the encrypted container, you will have to add an extra step, probably a call to kpartx, in the init scripts to scan that container for partitions.
If you use LUKS, the header on the device will proudly proclaim that this is a LUKS container and tell the encryption parameters, other than the key of course. You could hide that identification by using LUKS with a detached header stored elsewhere, or else set up the encryption without LUKS. For the latter, you will have to specify any non-default encryption parameters (cipher specification, hash method, key size, etc.) each time the container is unlocked.
for my case, it will be manually done when that encrypted device is needed. it will not be in init scripts. part of the intention is to make it look like an ordinary system booting up. it won't ask for the pass phrase until the script is run. that will happen manually. so kpartx can be in the "setupsdc" script.
As long as you will be manually invoking some script to set up the access, there is almost no limit to how and how deeply you can arrange the various levels of abstraction. Right now I'm looking at
Seem strange? Not at all, when you consider that "File 1" is actually the storage volume for a virtual machine, which then "does its thing" with partitioning, LVM, encryption, etc. I don't normally try to access anything below the level of "File 1" from the host, but I certainly could (given that I know the encryption key, of course).
And, if that virtual machine were hosting VMs of its own, then the nesting would continue on, deeper and deeper.
so it understands the filesystem used to distinguish File 1 and File 2? does it go through the kernel to do that? can that filesystem be concurrently mounted by the system level that has access to that image with the filesystem? can it use any filesystem type the kernel supports? can it do a collective RAID (randomly scattered pieces joined into one contiguous image)?
i'd prefer every byte on the entire drive look like total gibberish. maybe it would be better to have locations with actual filesystems be encrypted with a different key since those ready to crack the drive could be thinking "we know what LVM bytes look like. clue #1 to cracking her key."
so it understands the filesystem used to distinguish File 1 and File 2? does it go through the kernel to do that? can that filesystem be concurrently mounted by the system level that has access to that image with the filesystem? can it use any filesystem type the kernel supports? can it do a collective RAID (randomly scattered pieces joined into one contiguous image)?
File 1 and File 2 are on two separate filesystems. I'm not sure what you mean by "concurrently mounted," but no, the VM that uses File 1 as its virtual disk cannot be running if I want to mount that second filesystem from the host. This is just an example of how the layers can be nested. I'm not suggesting it as a solution to your problem.
At boot time, the physical drive is scanned for its partitions, the LVM logical volume is found, and the filesystem is mounted. Those first 4 levels all occur automtically -- it's normal boot behavior. If I want to look inside File 1 to find File 2, here's what I would do on the host:
Code:
# kpartx -av VM1raw.img
add map loop0p1 (253:8): 0 2097152 linear /dev/loop0 2048
add map loop0p2 (253:9): 0 69580800 linear /dev/loop0 2099200
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VM1vg" using metadata type lvm2
# vgchange -ay VM1vg
1 logical volume(s) in volume group "VM1vg" now active
# lvs VM1vg
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
vmroot VM1vg -wi-a----- 33.18g
# cryptsetup luksOpen /dev/VM1vg/vmroot xxx
Enter passphrase for /dev/VM1vg/vmroot:
# mount /dev/mapper/xxx /mnt/tmp
# cat /mnt/tmp/"File 2"
This is the content of the test file
# umount /mnt/tmp
# cryptsetup luksClose xxx
# vgchange -an VM1vg
0 logical volume(s) in volume group "VM1vg" now active
# kpartx -dv VM1raw.img
del devmap : loop0p2
del devmap : loop0p1
loop deleted : /dev/loop0
/dev/sdc will not be listed in /etc/fstab to be mounted. it is not to be mounted at boot time. a hidden script will mount it with an obscure prompt for the encryption passphrase. so what happens at boot time does not matter much. it will just boot up a simple Xubuntu.
/dev/sdc will not be listed in /etc/fstab to be mounted. it is not to be mounted at boot time. a hidden script will mount it with an obscure prompt for the encryption passphrase. so what happens at boot time does not matter much. it will just boot up a simple Xubuntu.
That's fine. You can arrange the layers any way you wish.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.