Is Ecryptfs "reasonably" safe for the average user?

That is, for some years I have heard and read that Ecryptfs was deprecated, insecure and unmantained. But also that it is already enough for an average user. I know LUKS, Veracrypt, is much better for full disk encryption, but they don't offer an easy dual boot solution for Windows-Ubuntu users. Certainly Ecryptfs isn't in Ubuntu repository for nothing, and is a very quick and easy method to crypt /home (or any directory) and /swap.

I appreciate comments.

I can't give you much guidance on this, but let me tell you something:

Be careful using EcryptFS. It's a slippery slope.

By default, when you install Ubuntu or a derivative and choose to enable an encrypted home folder, it doesn't encrypt swap as well. You can enable swap encryption, but the way it's done with EcryptFS you may not hibernate the computer using an encrypted swap partition.

Even worse possibly, a lot of applications store temporary files outside your home directory, thus defeating the encryption. LibreOffice by default stores all documents that have been opened in LibreOffice in /tmp. /tmp is not encrypted by default. Of course, you can work around this by telling LibreOffice (in the LibreOffice preferences) that you want LibreOffice to store its temporary files in a directory under your home directory. I'm not sure if other applications store stuff under /tmp, too. Next time you're using LibreOffice, look in the /tmp folder while you have a saved document open. You may be surprised.

Hi Gordon, really appreciate your comment.

Well in fact, crypt Swap with Ecryptfs is also possible, like other paths. Only you have to do is sudo ecryptfs-setup-swap and make a few changes in /etc/crypttab and /etc/fstab, reload cryptdisks and update initramfs. Terminal outcome is "/dev/mapper/cryptswap1 is active and is in use".
This do not admit hibernate, but allow suspend. No idea if this procedure allows suspend-then-hibernate, but this isn't a priority for lots users.

Relative to libreoffice, didn't know use /tmp/. In fact i don't use it, but I'm thinking that Thunderbird also can use it too for opening docs inside, so sure other software need it to run. Anyway Ubuntu can create a separate partition for /tmp/, like /var/ or /boot/, and also is possible to crypt this, or change default path /tmp/ for another, or reallocate it into /home/ making a link.

I also have the doubt that "old" must mean "deprecated" or "unsafe". So in Ubuntu how much code is in fact "unsafe"?? If Ecryptfs have some bugs, well, I don't mean it would be the only manner to decrypt /home, although in my case the restoration always worked perfectly. But perhaps could be "enough" if you use another backup systems regularly.

I mean that Ubuntu's internal policy with its workforce shouldn't influence what software really IS. Audits are almost always influenced by interests or sympathies.

It's enough, as long as you recognize the risk involved.

I think encrypting /tmp would be a good idea. A lot of apps use /tmp. If applications store stuff under /tmp unencrypted, why bother having an encrypted home directory?

Final pitfall: Once you log in, your files are decrypted into RAM (as necessary, on-the-fly). If you're worried about people hacking your Internet applications, you should be worried about people reading your sensitive files, too.

Just for the record. You're the ultimate judge. I can't tell you whether it's "safe enough" for your purposes. I'm just telling you about its disadvantages.

You're true right, Gordon. In fact, it's much safe use LUKS like I commented, so I really agree with Ubuntu default full disk encryption (if you use only Ubuntu). On two of my three computers I use this indeed with success.
For commenting, it seems tmp/ path autodeletes when every app stop using it for store temp files. Yeah, when shutdown, almost in my case, not docs or img are rested, includding hidden files.

Hacking? Of course, this is a risk. A good hacker is no possible to avoid. More concerned about a thief in a restaurant!

Sure, /tmp might get automatically cleared when the system is rebooted (it's actually cleared on system startup, so you can see some file residue from last startup if you inspect the /tmp directory from a live CD). But keep in mind that there are tools like e2undelete that can "undelete" files you thought were unrecoverable. I mean, if you're talking about a thief in a restaurant, that's physical access we're talking about. It might take a little command line prowess to use e2undelete or another tool, but even if the thief is not a techie, they can still steal the computer, remove the hard disk (or SSD -- whatever), and then ship the hard disk off for "data recovery" to get the myriad files from /tmp and other places. And do lock your screen or log out (or better yet, shut down) before you walk away from the computer in the restaurant: If the thief can access your logged-in user account, then the thief can read all your files.

Just sayin'.

1 Like

Hi Gordon, yes I know

Restaurant comment was a fun joke. Continuing our nice conversation, I really thought same as you: live Ubuntu and access to /tmp. But almost in thunderbird and text editors, temp docs are fully removed when you close the program that are using it, not when shutdown or reboot, almost in Focal. Yes, a data recovery can rescue some files, foremost, testdisk, lots that are very well-known in forensics.
Good, even with an SSD you can't entirely wipe your disk (ATA security erase enhanced). HDD admit zeroing/randoming, but in SSD you need a hammer. So almost you start installing ubuntu since FIRST time with full disk encryption, always will find vulnerabilities.
"do lock your screen or log out before you walk away from the computer in the restaurant". Never mind, my laptop comes with me to the WC haha.

Cheers

Just a thought with eCryptfs - as it's a laptop, it could take a criminal just a few minutes to boot a live session, plant a few files and put it back into the bag ready for the unsuspecting owner. :smiling_imp:

Even though the /home data may be "safe" and scrambled at rest , the remainder of the file system is exposed for tampering with who knows what - a keylogger, a hidden script or software modifications. That's just ready for a compromised system after you've logged in! :unlock: It's very unlikely of course, especially in a restaurant, but there could be someone with shifty eyes leaving USB drives on the ground... :slight_smile: As they say, a chain is only as strong as its weakest link.

So, to directly answer the topic's question - no, use full disk encryption during installation (powered by LUKS) for a secure system. Things only get a little tricky if you want to change the partition layout later, but the same could be said for any encrypted partition (e.g. Bitlocker on Windows)

1 Like

Now, I'll admit I don't have a clue exactly what underlying filesystem you're using on this laptop disk, be it BtrFS, ReiserFS, Ext4, whatever -- I can tell you from experience about Ext4 that undeleting files under certain circumstances is trivial.

Ext4 is a journalled filesystem. That means that whatever modification you make to a file (or technically a file's metadata -- only the metadata for a file is recorded in the journal by default), the modification is recorded in the journal "temporarily". That means the exact (meta)data modified is recorded in the journal at the time of the file save operation, and also a log entry about where that (meta)data belongs in the filesystem. It may surprise you, but initially that metadata is not written to the main filesystem per se; actually the operation to write stuff to the main filesystem is put off for (by default) 5 seconds after you save the file. After that timeout elapses, the metadata is written to the "inode table", the area in the main filesystem where filesystem metadata is stored. And the filesystem metadata includes:

  • The size of the file,
  • The date the file was last modified, and
  • The blocks on disk that the file occupies.

This is all information useful to an attacker. If you know the size of the file and the location where the file contents are stored on-disk, you've got the keys to the castle. I've experimented with this in the past. I've recovered (my own) confidential documents from /tmp before. And furthermore:

You may not expect it, but Ext4 is designed to avoid actually overwriting file data for as long as possible, spreading newer revisions of a file out over the disk in an attempt to even out the usage of the disk. By doing so, if you use the computer relatively casually, your documents that were "long deleted" may remain on-disk totally intact for months. It's not uncommon at all for the journal to use 256 MB on the disk; filesystem metadata is usually backed up only one block at a time, so every time you save a file you may only add 1 block (say 4096 bytes / 4 KB) to the journal. Barring directory modifications (directory contents also gets added to the journal), you could modify files 65,536 times before ever writing over any of the journal entries. On an average day for me, that might mean a few weeks of file modification. For someone else, it could mean months. Also consider: How big is your disk? And how big are the files that you edit? You may be surprised to find that, even if you on average save a 512 KB file every 10 minutes to a 500 GB disk, theoretically (and there are a lot of complications here) you may find that the file still hasn't been overwritten with other stuff at year's end.

It's really a good idea to look into the GNU shred utility if you value your privacy and possibly your money and well-being.

1 Like

Many many thanks @lah for your counselling. I follow all you posts with special attention. You are very true.

1 Like