You are not logged in.

#1 2018-03-24 14:16:44

LeftyAce
Member
Registered: 2012-08-18
Posts: 159

Individual encrypted containers -- use LVM thin provisioning?

Hi all,

I'm running full disk encryption using dm-crypt/LUKS. I would like to add modular encryption on top of it, for example:

/home/lefty/container1 encrypted with key1, only unlocked when needed.
/home/lefty/container2 encrypted with key2, only unlocked when needed.

Based on the comparison table in the wiki, I don't think I want eCryptFS or encFS, since they still expose the file metadata. I would like the container to look like a single blob when it's locked.

What is the best way to achieve this?

One idea I had was to use LVM, and create thin provisioned volumes...for example, container1 and container2 would each be allocated a size equal to the whole disk, but I think with thin provisioning, they would only actually consume the amount of space needed to hold their contents. Each would be able to expand in size as needed to hold their contents.

Would that work? Is there an easier way to do this? Thanks in advance!

-Lefty

Offline

#2 2018-03-24 14:20:30

damjan
Member
Registered: 2006-05-30
Posts: 451

Re: Individual encrypted containers -- use LVM thin provisioning?

Offline

#3 2018-03-24 16:39:16

mxfm
Member
Registered: 2015-10-23
Posts: 163

Re: Individual encrypted containers -- use LVM thin provisioning?

Maybe I don't understand the question (what is 'modular encryption'?) but you can encrypt a file with cryptsetup/LUKS like a partition (with fstab settings), although this requires fixed file size.

Last edited by mxfm (2018-03-25 05:09:29)

Offline

#4 2018-03-24 16:46:35

LeftyAce
Member
Registered: 2012-08-18
Posts: 159

Re: Individual encrypted containers -- use LVM thin provisioning?

I don't see the difference between ext4 encryption and encFS or eCryptFS (in terms of functionality. I'm not concerned with performance for this). All three result in individual encrypted files, when ideally I'd like to have the container look like a single blob when it's locked. Maybe I need to give up on that.

What I meant by "modular encryption" is the ability to lock specific folders with their own keys/passphrases. The fixed file size aspect of using LUKS inside a file is why I'm avoiding it. My end goal is to have a 'financials' folder where I put financial stuff so it isn't always unlocked when my home partition is unlocked...I will be adding and removing files over time, so the size fluctuate.

Offline

#5 2018-03-24 16:50:04

frostschutz
Member
Registered: 2013-11-15
Posts: 1,409

Re: Individual encrypted containers -- use LVM thin provisioning?

You can combine LUKS and thin provisioning.

The usual limitations apply (regardless of encryption). If you overcommit your storage, all hell breaks loose when you try to use more than what the storage can actually provide.

----

Another problem is how to make sure things stay inside their containers and not out. You delete a file, it's moved to a trashcan - outside the container. Some editors or programs may have auto-backup or history or config related or temporary files outside the container.

For the same reason a lot of people choose to do full disk encryption instead of just encrypting individual home folders... that way everything is covered and there is nothing "outside" the encryption.

Last edited by frostschutz (2018-03-24 17:06:12)

Offline

#6 2018-03-24 17:20:34

LeftyAce
Member
Registered: 2012-08-18
Posts: 159

Re: Individual encrypted containers -- use LVM thin provisioning?

frostschutz, do you mean without LVM? Or is LVM with thin provisioning the best way to do this?

I've seen examples of creating a luks partition inside a sparse file to achieve what I'm after. Is that what you're referring to?

It looks like there are two danger scenarios:

1) Overcommitting: if I have a "100 GB" sparse file, and I only actually have 50 GB of free space on the disk, the moment I try to write more than 50 GB to that sparse file, all hell breaks loose. Is it worse than just trying to write a new file to a normal partition that's full? Will I just lose the file I'm trying to write, or am I going to lose files that were previously successfully written? If I keep track of my disk usage with 'df', I think I can see this problem coming and react accordingly, right? (This is a single user laptop, it takes me years to fill a given hard drive).

2) Overfilling: Suppose I create a 5 GB sparse file (on a disk with 50 GB of freespace). I create a luks volume in the file, mount it, etc. Then I try to write 6x 1 GB files to my 5 GB sparse file. What happens? Do the first 5 survive just fine, and the 6th gives me a normal "not enough space" error?

Offline

#7 2018-03-24 17:30:04

frostschutz
Member
Registered: 2013-11-15
Posts: 1,409

Re: Individual encrypted containers -- use LVM thin provisioning?

LVM or sparse file, up to you. I would probably trust LVM more - it easier to get a hold of its metadata. With sparse files you completely depend on the filesystem that holds them. If that filesystem goes corrupt for any reasons, you lose all your files (and sparse file containers).

Is it worse than just trying to write a new file to a normal partition that's full?

If you can't write to a file you have a damaged file. If you can't write to a filesystem-in-a-file, you likely have a damaged filesystem. It is possible to lose the entire container(s) in one go.

The question is, do you really want thin provisioning at all? With LVM you could adapt volume sizes any time you like (provided your filesystem is one that allows resizing both ways, growing and shrinking).

Offline

Board footer

Powered by FluxBB