Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.
Sign up to join this community
Let's say that I have a folder, within my Documents folder, that has files I want no one to access without a password.
Is there a way to lock down that folder so that it's password protected / encrypted?
In fact, is it possible to password-protect any individual folder?
WARNING: CryptKeeper has recently been reported that it has a universal password bug that puts your data at potential risk. This issue may not yet be fixed in Ubuntu, use this solution at your own risk.
Relevant bug information links:
Upstream bug: https://github.com/tomm/cryptkeeper/issues/23
Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852751
sudo apt-get install cryptkeeper
After installing, go to Applications –> System Tools –> Cryptkeeper.
Cryptkeeper will automatically attach itself to the top panel
To create an encrypted protected folder, click on Cryptkeeper applet and select ‘New encrypted folder’
Then type the folder name and where to save the folder and click ‘Forward’.
Type the password and click ‘Forward’.
The folder will be created and ready to be used.
To access all encrypted folder, click on Cryptkeeper applet on the panel and select each folder.
Type the password before it is mounted to be accessed.
To delete a folder or change the password, right-click the folder in the panel-applet.
gsettings set com.canonical.Unity.Panel systray-whitelist "['all']" and unity --replace.
com.canonical.Unity.Panel doesnt exist, and systray-whitelist is an invalid key in all available Unity. schemas :(
Apr 28, 2014 at 8:00
EncryptedPrivateDirectory Method.
Search for and install ‘ecryptfs-utils’ in Ubuntu Software Center:
After installing, go to Applications –> Accessories –> Terminal and run the command below:
ecryptfs-setup-private
You’ll be prompted to type your login passphrase (password), and to create one for your private folder:
When you’re done creating your password, Log Out and Log back in:
Next, go to Places –> Home Folder:
And new folder should be created in your home directory called ‘Private’. This folder in encrypted and password-protected. Move all your personal stuff into this folder to secure them:
You have 2 choices if you want to lock down a folder from other users
Encrypt or create a compressed password protect archive of the files. This method (Cryptkeeper) is perfect for this case when you need to be 100% sure no one will ever look at your files without knowing the password used there.
Use your computer folder / file permissions to deny access to your folder to other user.
The first involves making sure that the result cannot be opened by any user without knowing the password used.
The second will only change the file / folder privileges so that another user without rights cannot open it. The folder still exists, can be accessed by any user with sudo rights in your system or using a LiveCD and reading the partition. It is also simpler to implement and does not require that you type a password all the time you need to open / mount the encrypted folder / archive.
An easy and fast way to do so is using chmod to change the privileges for a file or folder.
Open a terminal and navigate to the place where your folder is, lets assume that the folder name is foo and that we are currently located where the folder is.
chmod 700 foo
will make foo only available for your eyes, its not encrypted (that is also possible) but only your user (and or a user with sudo privileges) can read or open that file / folder.
You can also do it graphically by right clicking on a file or folder and changing its permissions manually. In the example below you as owner have all privileges and you deny any other group or user from accessing, reading or modifying that file / folder
For more information about file / folder permissions visit the Ubuntu Understanding and Using File Permissions wiki page.
chmod 700 <folder_name> in a terminal.
Feb 16, 2012 at 10:01
Another way, depending on your needs is to archive the folder as a password protected zip file.
This is similar to another question about password protecting files.
You can use CryFS:
cryfs basedir mountdir
It is used by default in KDE Vaults and is particularly interesting if you synchronize the encrypted content over Dropbox, Freefilesync, rsync or similar software, because it keeps its data in small encrypted blocks and changing a small file results in only a small amount of data to be re-uploaded.
cryfs because it doesn't support (standard Unix) hard links.
Last update: Aug 4, 2012
You can try Vault, recent project by an ubuntu-gr member (greek local community).
PPA:
sudo add-apt-repository ppa:vault/ppa
sudo apt-get update
sudo apt-get install vault
It's a gui utility for encfs (package in repositories). I quote the package description:
$ apt-cache show encfs
Package: encfs
[...]
Description-en: encrypted virtual filesystem
EncFS integrates file system encryption into the Unix(TM) file system.
Encrypted data is stored within the native file system, thus no
fixed-size loopback image is required.
.
EncFS uses the FUSE kernel driver and library as a backend.
Homepage: http://www.arg0.net/encfs
You create a mountpoint/folder which you can then close or delete. If you close it, you need a password to open it.
Directory level encryption is a risky thing, prefer block device level encryption whenever possible.
I think Giles nailed several key points here, which I'll reproduce:
Use encryption at the block device level. Linux provides this with dm-crypt. You can encrypt either the whole disk (except for a small area for the bootloader), or encrypt
/homeor some other partition. If you don't encrypt the whole disk, keep in mind that confidential information might end up in other places, especially the swap space (if you have any encrypted data anywhere, you should encrypt your swap). Note that if you go for whole-disk encryption, your computer will not be able to boot unattended, you will have to type your passphrase at the keyboard.Since the whole block device is encrypted, the location of file content and metadata cannot be detected by an attacker who steals the disk. Apart from a header at the beginning of the encrypted area, the content is indistinguishable from random noise. An attacker could derive some information from seeing multiple snapshots of the encrypted data and studying how various sectors evolve over time, but even with this it would be hard to find out anything interesting, and this doesn't apply if you stop modifying the data after the attacker has seen the ciphertext (as in the case of a disk theft).
Also note that if you encrypt something inside your home and not the entire home itself, several common programs can lead to data leaks unless you are hair splittingly careful. E.g.: .bash_history, editor sessions and undo histories, etc.
Some pointers on how to do this:
fscrypt after a non-encrypted installation (the installer has an option to encrypt the home directory)
eCryptfs manual setup
This answer described the Ubuntu helpers for it (e.g. ecryptfs-setup-private), but you can get more control (e.g. separate different mount directories) and understanding by mounting it yourself.
eCryptfs is already part of the Linux kernel and already enabled by default on Ubuntu via CONFIG_ECRYPT_FS=y, so you can just basically mount it. Being part of the kernel is also generally a positive indicator of quality and stability.
I have the following helpers:
export ECRYPTFS_DIR="$HOME/ecryptfs"
export ECRYPTFS_DATA_DIR="$HOME/.ecryptfs-data"
ecry() (
# Mount ecryptfs.
if ! mountpoint -q "$ECRYPTFS_DIR"; then
sudo mount -t ecryptfs \
-o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes \
"$ECRYPTFS_DATA_DIR" \
"$ECRYPTFS_DIR"
fi
)
ecryu() (
# Unmount ecryptfs.
sudo umount "$ECRYPTFS_DIR"
)
Usage is as follows.
First mount the encrypted directory:
ecry
This will now ask you for a passphrase:
Passphrase:
Suppose we unwisely choose:
asdf
so it will now print:
Filename Encryption Key (FNEK) Signature [87d04721f6b4fff1]:
87d04721f6b4fff1 is a type of hash derived from our asdf password. You can now hit enter, and it will say:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=87d04721f6b4fff1
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=87d04721f6b4fff1
Mounted eCryptfs
which means that the mount was successful.
Now let's make some test encrypted files:
echo AAAA > ~/ecryptfs/aaaa
echo BBBB > ~/ecryptfs/bbbb
dd if=/dev/zero bs=1k count=1k > ~/ecryptfs/zzzz
If we unmount it:
ecry
as expected the directory is empty:
ls -l ~/ecryptfs
The eCryptfs data itself is contained in the ~/.ecryptfs-dat directory we passed to the mount command.
No matter where we mount to, as long as we use that directory as the data directory, the contents of the unencrypted mount point will be the same.
Let's observe its contents:
ls -lh ~/.ecryptfs-data
This shows three encrypted files:
-rw-rw-r-- 1 ciro ciro 12K Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZB.pJ2KyM4SRZWVvHGnAYi---
-rw-rw-r-- 1 ciro ciro 12K Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZMnVJY0WbH6bqRaee1cD5xU--
-rw-rw-r-- 1 ciro ciro 1.1M Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZf.vz0tLUzh41PwVFAnHc5k--
So we observe that:
We can now check if those files are actually encrypted:
grep aaaa ~/.ecryptfs-data/*
grep AAAA ~/.ecryptfs-data/*
which gives no matches, so they likely are encrypted.
The cool thing about how those encrypted files are stored, is that you can then easily backup the encrypted files anywhere by just copying them over to an unencrypted medium with rsync, and only out-of-date files will be copied. There is no need to even first enter your password in that case!
The non-cool thing about it, is that an attacker who is trying to prove that you had a known piece of information might be able to prove that by comparing the file sizes and directory structure layout as mentioned by Giles.
Now let's mount again:
ecry
Once again, it asks for the password.
Suppose you enter the wrong password:
asdfqwer
it will now print:
Filename Encryption Key (FNEK) Signature [c55c6f13e73332d3]:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=c55c6f13e73332d3
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=c55c6f13e73332d3
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? :
So we observe that the FNEK for asdfqwer is different than that of the correct asdf password: c55c6f13e73332d3.
If we decide to mount anyways with yes, it then asks:
Would you like to append sig [c55c6f13e73332d3] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? :
and if we enter yes, it would, as promised add the FNEK to the /root/.ecryptfs/sig-cache.txt. Let's say no for now. We can check what that file contains:
sudo cat /root/.ecryptfs/sig-cache.txt
it currently only contains the asdf FNEK:
87d04721f6b4fff1
so we understand that it is just a whitelist of known good passwords.
Now let's see what we get with the wrong password:
ls -l ~/ecryptfs
and we see that the directory is empty as you might expect. It seems that each file in the data directory must contain some kind of password check data, and just doesn't get mounted.
If we umount and move back to the correct password asdf, it wil once again ask for FNEK confirmation which is a bit annoying.
Filename Encryption Key (FNEK) Signature [87d04721f6b4fff1]:
We can prevent that from happening every time as mentioned at How to automatically specify the Filename Encryption Key with ecryptfs? by adding:
-o ecryptfs_fnek_sig=
to the mount command. TODO would knowing the FNEK help attackers crack the password?
Finally, when the ecryptfs directory mounted, we can see it under:
grep ecryptfs /proc/mounts
which contains a line of type:
/home/ciro/.ecryptfs-data /home/ciro/ecryptfs ecryptfs rw,relatime,ecryptfs_fnek_sig=d066f6dcf72ad65a,ecryptfs_sig=d066f6dcf72ad65a,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
Tested on Ubuntu 20.04, Linux kernel 5.4.
ecryptfs vs CryFS vs EncFS
These are all directory-level methods so it would be good to understand their tradeoffs, Some comparisons:
https://wiki.archlinux.org/index.php/EncFS#Comparison_to_eCryptFS
eCryptFS is implemented in kernelspace and therefore a little bit harder to configure. You have to remember various encryption options (used cyphers, key type, etc...). With EncFS this is not the case, because it stores the encryption metadata information in a per-directory configuration file (.encfs6.xml). So you do not have to remember anything (except the passphrase).
The performance of both depends on the type of disk activity. While eCryptFS can perform faster in some cases because there is less overhead by context switching (between kernel and userspace), EncFS has advantages in other cases because the encryption metadata is centralized and not stored in the individual files' headers. For more information benchmark examples are provided by the EncFS project.
Full disk encryption at install time (except /boot)
I can't find "the question" for this, so here goes a QEMU experiment based here with Ubuntu 20.04.1.
You click:
Then it asks you for a password on the next step:
Now, every time you boot, the very first thing you see, (TODO before or after the bootloader?), is a password prompt:
And after this, if you enter the correct password, it goes into a normal boot.
After logging in, from inside a shell we do:
lsblk
and that gives:
sda 8:0 0 1T 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 731M 0 part /boot
└─sda6 8:6 0 1022.8G 0 part
└─sda6_crypt 253:0 0 1022.8G 0 crypt
├─vgubuntu-root 253:1 0 1021.8G 0 lvm /
└─vgubuntu-swap_1 253:2 0 976M 0 lvm [SWAP]
so it appears that the second stage bootloader under /boot itself is not encrypted, but the root directory and swap are.
As mentioned at: https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019 this opens you to the risk that an attacker would be able to compromise your machine by tampering with the boot folder, without your knowledge, and use that to later extract your decryption keys if you continue to use the machine.
Full disk encryption at install time (including /boot)
There doesn't seem to be an automated way of doing it as of 20.04, but hopefully it will get implemented sooner or later, some manual guides:
Kill switch turned on laptop encryption security
OK, we are now reaching a CIA/Silk Road level of opsec paranoia topic: how to quickly ensure that your data can't be decrypted if you are caught with the computer turned on and have a second to act.
First, suspend to RAM does not seem to be good enough, hibernation will be a wiser move:
Hibernation seems to save data in the swap partition, so as long as your swap is encrypted (Which it obviously should be in an encryption setting, otherwise your RAM will leak there), it should be safe.
Now, on a laptop, the best method is likely a lid closing action, e.g. this post mentions that:
HandleLidSwitch=hibernate
on /etc/systemd/logind.conf should work
Alternatively should setup a keyboard shortcut or a power button action. How to hibernate from CLI: How can I hibernate on Ubuntu 16.04? mentions:
sudo systemctl hibernate
You could also use gocryptfs. In my experience it is significantly faster than cryfs with big encrypted shares, but does not hide the structure (file sizes and number of files). depending on your threat model this may or may not be a problem.
To install
apt install gocryptfs
To initialize the basedir (once)
gocryptfs -init basedir
To mount basedir (the encrypred version) on mountdir (the unencrypted version)
gocryptfs basedir mountdir