Linux encrypt home folder

Ubuntu Documentation

Please refer to EncryptedFilesystems for further documentation.

There are two ways to encrypt files and directories within your home directory. You can either place files in an encrypted «Private» directory, or you can encrypt your entire Home directory.

Encrypted Private

Ubuntu allows you to encrypt a «Private» directory within your home directory. This provides strong cryptographic protection of your most sensitive data, such as your documents and keys. This directory is automatically mounted on login, and unmounted on logout. When the directory is unmounted, an attacker only has access to your encrypted data (AES256), and not the files or directories stored within.

The encrypted data is in $HOME/.Private, and when mounted, the decrypted data is in $HOME/Private. Some important configuration information is stored in $HOME/.ecryptfs.

During the installation process, there is a question in the installation for configuring the Encrypted Private directory. If you want to setup your Encrypted Private directory later, just run ecryptfs-setup-private.

Encrypted Home

Ubuntu makes it possible to set up Home directory encryption using the Desktop CD. On the User Setup screen, after choosing a username and a password, the user can choose one of:

• log in automatically
• require a password to log in
• require a password to log in and decrypt your home directory

Users wanting an Encrypted Home directory should choose the 3rd option.

If the administrator wants to add a new user with an encrypted home directory after the initial installation, use: sudo adduser --encrypt-home. This requires the ecryptfs-utils package.

If the user wants to migrate from a non-encrypted home directory to an Encrypted Home directory, follow the instructions here:

In the Ubuntu 9.04 setup, the user’s encrypted data is located in $HOME/.Private, but is only available when $HOME is not mounted. The user’s configuration data is in /var/lib/ecryptfs/$USER.

Note that this has been problematic for some users who remember to back up their /home partition, but neglect to back up their /var/lib/ecryptfs partition. This has been fixed in Ubuntu 9.10.

In the Ubuntu 9.10 setup, the user’s encrypted data is located in /home/.ecryptfs/$USER/.Private, and the user’s configuration data is located in /home/.ecryptfs/$USER/.ecryptfs. As such, all of the user’s pertinent data is self-contained in /home.

Caveats

There are a few minor caveats that one must keep in mind about these encrypted configurations.

When you are not logged into your system, data in your home directory is not accessible in plain text. This, of course, is by design. This is what keeps an attacker from gaining access to your files. However, this means that:

Your cronjobs may not have access to your Home Directory

SSH public key authentication into your system also will not work, unless you put your public key somewhere outside of your home directory and symbolically link it to your unmounted $HOME/.ssh/authorized_keys.

You can put your authorized_keys directly in your unencrypted home directory by following these directions without the need for linking it anywhere else. https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12

Also, it is strongly recommended that you encrypt your swap space. Users installing from Ubuntu 9.10 and selecting the Encrypted Home option will automatically have encrypted swap space. Other users can run sudo ecryptfs-setup-swap. This is critically important, because your home directory data will appear as cleartext in memory, as the kernel reads your encrypted data. If the kernel swaps this data to disk, it could potentially leak your decrypted data back to disk, totally defeating your Encrypted Home. Encrypted Swap solves this problem. However:

• Hibernation will not work. Actually, hibernation will work just fine. But you can’t resume. There are ways around this, but it involves choosing a password to use for your swap encryption, and entering that password every time you boot your system, and sharing that password with anyone else that might want to resume the system.
• This is a known, wishlist issue that we hope to solve for Ubuntu 10.04.
• You may be able to avoid these problems by running without a swapfile.

Beware of information from an encrypted directory leaking out (the linked article is Windows-centric but the same principle apply to Linux).

• It is unclear if and if so, how much, using an encrypted home impacts performance, especially on low-end machines
• What are the risks/chances of a breaking file system for recovering encrypted data?

EncryptedHome (последним исправлял пользователь imnichol 2014-11-24 01:11:48)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

eCryptfs

This article describes basic usage of eCryptfs. It guides you through the process of creating a private and secure encrypted directory within your home directory to store sensitive files and private data.

In implementation eCryptfs differs from dm-crypt, which provides a block device encryption layer, while eCryptfs is an actual file-system – a stacked cryptographic file system. For comparison of the two you can refer to the Data-at-rest encryption#Comparison table. One distinguished feature is that the encryption is stacked on an existing filesystem; eCryptfs can be mounted onto any single existing directory and does not require a separate partition (or size pre-allocation).

Contents

Basics

As mentioned in the summary eCryptfs does not require special on-disk storage allocation effort, such as a separate partition or pre-allocated space. Instead, you can mount eCryptfs on top of any single directory to protect it. That includes, for example, a user’s entire home directory or single dedicated directories within 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 other advantages, but there are also drawbacks, for instance eCryptfs is not suitable for encrypting complete partitions which also means you cannot protect swap space with it (but you can, of course, combine it with Dm-crypt/Swap encryption). If you are just starting to set up disk encryption, swap encryption and other points to consider are covered in Data-at-rest encryption#Preparation.

To familiarize with eCryptfs a few points:

• As a stacked filesystem, a mounting of an eCryptfs directory refers to mounting a (stacked) encrypted directory to another unencrypted mount point (directory) at Linux kernel runtime.
• It is possible to share an encrypted directory between users. However, the encryption is linked to one passphrase so this must be shared as well. It is also possible to share a directory with differently encrypted files (different passphrases).
• Several eCryptfs terms are used throughout the documentation:
  • The encrypted directory is referred to as the lower and the unencrypted as the upper directory throughout the eCryptfs documentation and this article. While not relevant for this article, the Overlay filesystem introduced with Linux 3.18 uses the same upper/lower nomenclature for the stacking of filesystems.
  • The mount passphrase (or key) is what gives access to the encrypted files, i.e. unlocks the encryption. eCryptfs uses the term wrapped passphrase to refer to the cryptographically secured mount passphrase.
  • FEFEK refers to a File’s Encryption key Encryption Key (see kernel documentation).
  • FNEK refers to a File Name Encryption Key, a key to (optionally) encrypt the filenames stored in the encrypted directory.

Before using eCryptfs, the following disadvantages should be checked for applicability.

Deficiencies

• Ease of use

The ecryptfs-utils package provides several different ways of setting up eCryptfs. The high-level #Ubuntu tools are the easiest to use, but they hard-code the lower directory path and other settings, limiting their usefulness. The package also includes low-level tools which are fully configurable, but they are somewhat more difficult to use compared to alternatives like EncFS.

• File name length

File names longer than 143 bytes cannot be encrypted (with the FNEK option) when stacked on a filesystem with a maximum file name length of 255 bytes.[1] This can break some programs in your home directory (for example Symfony caching).

• Network storage mounts

eCryptfs has long-standing bugs when used on top of NFS and possibly other networked filesystems, for example, #Mounting may fail on a remote host when connecting via Mosh. It is always possible to use eCryptfs on a local directory and then copy the encrypted files from the local directory to a network host. However, if you want to set up eCryptfs directly on top of an NFS mount, with no local copy of the files, eCryptfs may crash or behave incorrectly. If in doubt, EncFS may be a better choice in this case.

• Sparse files

Sparse files written to eCryptfs will produce larger, non-sparse encrypted files in the lower directory. For example, in an eCryptfs directory running truncate -s 1G file.img creates a 1GB encrypted file on the underlying filesystem, with the corresponding resource (disk space, data throughput) requirements. If the same file were created on an unencrypted filesystem or a filesystem using block device encryption, it would only take a few kilobytes. This should be considered before encrypting large portions of the directory structure, though in most cases the disadvantages will be minor. If you need to use large sparse files, you can work around this issue by putting the sparse files in an unencrypted directory or using block device encryption for them.

Setup & mounting

Before starting, check the eCryptfs documentation. It is distributed with a very good and complete set of manual pages.

eCryptfs has been included in Linux since version 2.6.19. Start by loading the ecryptfs module:

To actually mount an eCryptfs filesystem, you need to use userspace tools provided by the package ecryptfs-utils available in the Official repositories. Unfortunately, due to the poor design of these tools, you must choose between three ways of setting up eCryptfs with different tradeoffs:

Use the high-level #Ubuntu tools, which set things up automatically but require the lower directory to be

/.Private/ , and allow only one encrypted filesystem per user.

Use ecryptfs-simple, available from AUR, which is an easy way to mount eCryptfs filesystems using any lower directory and upper directory.

#Manual setup, which involves separate steps for loading the passphrase and mounting eCryptfs, but allows complete control over the directories and encryption settings.

Ubuntu tools

Most of the user-friendly convenience tools installed by the ecryptfs-utils package assume a very specific eCryptfs setup, namely the one that is officially used by Ubuntu (where it can be selected as an option during distro installation). Unfortunately, these choices are not just default options but are actually hard-coded in the tools. If this set-up does not suit your needs, then you can not use the convenience tools and will have to follow the steps at #Manual setup instead.

The set-up used by these tools is as follows:

• each user can have only one encrypted directory that is managed by these tools:
  • either full $HOME directory encryption, or
  • a single encrypted data directory (by default

  /Private/ , but this can be customized).

the lower directory for each user is always

/.Private/
(in the case of full home dir encryption, this will be a symlink to the actual location at /home/.ecryptfs/$USER/.Private/ )

the encryption options used are:

• cipher: AES
• key length: 16 bytes (128 bits)
• key management scheme: passphrase
• plaintext passthrough: enabled

the configuration / control info for the encrypted directory is stored in a bunch of files at

/.ecryptfs/ :
(in the case of full home dir encryption, this will be a symlink to the actual location at /home/.ecryptfs/$USER/.ecryptfs/ )

• Private.mnt [plain text file] — contains the path where the upper directory should be mounted (e.g. /home/lucy or /home/lucy/Private )
• Private.sig [plain text file] — contains the signature used to identify the mount passphrase in the kernel keyring
• wrapped-passphrase [binary file] — the mount passphrase, encrypted with the login passphrase
• auto-mount , auto-umount [empty files] — if they exist, the pam_ecryptfs.so module will (assuming it is loaded) automatically mount/unmount this encrypted directory when the user logs in/out

Encrypting a data directory

For a full $HOME directory encryption see #Encrypting a home directory

Before the data directory encryption is setup, decide whether it should later be mounted manually or automatically with the user log-in.

To encrypt a single data directory as a user and mount it manually later, run:

and follow the instructions. The option —nopwcheck enables you to choose a passphrase different to the user login passphrase and the option —noautomount is self-explanatory. So, if you want to setup the encrypted directory automatically on log-in later, just leave out both options right away.

The script will automatically create the

/.ecryptfs/ directory structures as described in the box above. It will also ask for two passphrases:

login passphrase This is the password you will have to enter each time you want to mount the encrypted directory. If you want auto-mounting on login to work, it has to be the same password you use to login to your user account. mount passphrase This is used to derive the actual file encryption master key. Thus, you should not enter a custom one unless you know what you are doing — instead press Enter to let it auto-generate a secure random one. It will be encrypted using the login passphrase and stored in this encrypted form in

/.ecryptfs/wrapped-passphrase . Later it will automatically be decrypted («unwrapped») again in RAM when needed, so you never have to enter it manually. Make sure this file does not get lost, otherwise you can never access your encrypted folder again! You may want to run ecryptfs-unwrap-passphrase to see the mount passphrase in unencrypted form, write it down on a piece of paper, and keep it in a safe (or similar), so you can use it to recover your encrypted data in case the wrapped-passphrase file is accidentally lost/corrupted or in case you forget the login passphrase.

The mount point («upper directory») for the encrypted folder will be at

/Private by default, however you can manually change this right after the setup command has finished running, by doing:

To actually use your encrypted folder, you will have to mount it — see #Mounting below.

Encrypting a home directory

The wrapper script ecryptfs-migrate-home will set up an encrypted home directory for a user and take care of migrating any existing files they have in their not yet encrypted home directory.

To run it, the user in question must be logged out and own no processes. The best way to achieve this is to log the user out, log into a console as the root user, and check that ps -U username returns no output. You also need to ensure that you have rsync , lsof , and which installed. Once the prerequisites have been met, run:

and follow the instructions. After the wrapper script is complete, follow the instructions for auto-mounting — see #Auto-mounting below. It is imperative that the user logs in before the next reboot, to complete the process.

Once everything is working, the unencrypted backup of the users home directory, which is saved to /home/username.random_characters , can and should be deleted.

Mounting

Manually

Executing the wrapper

and entering the passphrase is all needed to mount the encrypted directory to the upper directory

/Private , described in #Ubuntu tools.

will unmount it again.

The tools include another script that can be very handy to access an encrypted .Private data or home directory. Executing ecryptfs-recover-private as root will search the system (or an optional specific path) for the directory, interactively query the passphrase for it and mount the directory. It can, for example, be used from a live-CD or different system to access the encrypted data in case of a recovery. Note that if booting from an Arch Linux ISO you must first install the ecryptfs-utils to it. Further, it will only be able to mount .Private directories created with the Ubuntu tools.

Auto-mounting

The default way to auto-mount an encrypted directory is via PAM. See pam_ecryptfs(8) and — for more details — ‘PAM MODULE’ in:

For auto-mounting it is required that the passphrase to access the encrypted directory is synchronised with the user log-in.

The following steps set it up:

/.ecryptfs/wrapped-passphrase exist (these are automatically created by ecryptfs-setup-private).

2. Add ecryptfs to the pam-stack exactly as following to allow transparent unwrapping of the passphrase on login:

Open /etc/pam.d/system-auth and after the line containing auth required pam_unix.so (or auth [default=die] pam_faillock.so authfail if present) add:

Next, above the line containing password required pam_unix.so (or -password [success=1 default=ignore] pam_systemd_home.so if present) insert:

And finally, after the line session required pam_unix.so add:

3. Re-login and check output of mount which should now contain a mountpoint, e.g.:

for the user’s encrypted directory. It should be perfectly readable at

The latter should be automatically unmounted and made unavailable when the user logs off.

ecryptfs-simple

Use ecryptfs-simple if you just want to use eCryptfs to mount arbitrary directories the way you can with EncFS. ecryptfs-simple does not require root privileges or entries in /etc/fstab , nor is it limited to hard-coded directories such as

/.Private . The package is available to be installed as ecryptfs-simple AUR and from Xyne’s repos.

As the name implies, usage is simple:

Automatic mounting: prompts for options on the first mount of a directory then reloads them next time:

Unmounting by source directory:

Unmounting by mountpoint:

Manual setup

The following details instructions to set up eCryptfs encrypted directories manually. This involves two steps. First, the passphrase is processed and loaded into the kernel keyring. Second, the filesystem is actually mounted using the key from the keyring.

There are two ways to add the passphrase to the kernel keyring in the first step. The simpler option is ecryptfs-add-passphrase , which uses a single passphrase to encrypt the files. The disadvantage is that you cannot change the passphrase later. It works like this:

You can also pipe a passphrase into ecryptfs-add-passphrase — . Keep in mind that if you leave your passphrase in a file, it will usually defeat the purpose of using encryption.

As an alternative to a plain passphrase, you can use a «wrapped passphrase», where the files are encrypted using a randomly generated key, which is itself encrypted with your passphrase and stored in a file. In this case, you can change your passphrase by unwrapping the key file with your old passphrase and rewrapping it using your new passphrase.

In the following we prompt for the wrapping passphrase and do a generation similar to the source and then use ecryptfs-wrap-passphrase to wrap it with the given password to

Do not use a passphrase with more than 64 characters as this will result in an error later when using ecryptfs-insert-wrapped-passphrase-into-keyring .

Next, we can enter our passphrase to load the key into the keyring:

In either case, when you successfully add the passphrase to the kernel keyring, you will get a «key signature» like 78c6f0645fe62da0 which you will need in the next step.

There are two different ways of manually mounting eCryptfs, described in the following sections. The first way, using mount.ecryptfs_private , can be run as a regular user and involves setting up some configuration files. This method does not allow you to change the encryption settings, such as key size. The second way is to use a raw mount command, which gives you complete control over all settings, but requires you to either run it as root, or add an entry to /etc/fstab which lets a user mount eCryptfs.

With configuration files

This method involves running mount.ecryptfs_private from the ecryptfs-utils package, after first loading your passphrase. This binary requires no root privileges to work by default.

First choose a name for your configuration files in

/.ecryptfs and decide on the lower and upper directories. In this example we use secret for the configuration files, put in encrypted data in

/.secret , and mount the decrypted files at

/secret . Create the required directories:

Now specify the directories in

/.ecryptfs/secret.conf , using full paths. Its format looks like the one in /etc/fstab without the mount options:

Write the key signature you got from ecryptfs-add-passphrase or ecryptfs-insert-wrapped-passphrase-into-keyring (see above) into

If you also want to enable filename encryption, add a second passphrase to the keyring (or reuse the first passphrase) and append its key signature to

When you are done, unmount it:

Raw mount command

By running the actual mount command manually, you get complete control over the encryption options. The disadvantage is that you need to either run mount as root, or add an entry to /etc/fstab for each eCryptfs directory so users can mount them.

First create your private directories. In this example, we use the same ones as the previous section:

Actual encrypted data will be stored in the lower

/.secret directory
While mounted, decrypted data will be available in

/secret directory

• While not mounted nothing can be written to this directory
• While mounted it has the same permissions as the lower directory

Now, supposed you have created the wrapped keyphrase above, you need to insert the encryption key once to the root user’s keyring:

so that the followng mount command succeeds:

• ecryptfs_sig sets the data passphrase key signature.
• ecryptfs_fnek_sig sets the filename passphrase key signature; you can omit this option if you do not want to encrypt filenames.
• ecryptfs_key_bytes can be 16, 24, or 32 to change the encryption key size.
• ecryptfs_unlink_sigs will remove the passphrase(s) from the keyring when you unmount, so you have to add the passphrase(s) back again in order to re-mount the filesystem.
• There are a few other options listed in the ecryptfs man page.

Once you have chosen the right mount options, you can add an entry to /etc/fstab so regular users can mount eCryptfs on these directories. Copy the mount options to a new /etc/fstab entry and add the options user and noauto . The full entry will look similar to (bold entries added):

• The noauto option is important, because otherwise systemd will error trying to mount the entry directly on boot.
• The user option enables to mount the directory as a user.
  • The user mount will default to option noexec . If you want to have at least executable files in your private directory, you can add exec to the fstab options.

The setup is now complete and the directory should be mountable by the user.

Mounting

To mount the encrypted directory as the user, the passphrase must be unwrapped and made available in the user’s keyring. Following above section example:

Now the directory can be mounted without the mount helper questions:

and files be placed into the secret directory. The above two steps are necessary every time to mount the directory manually.

To unmount it again:

To finalize, the preliminary passphrase to wrap the encryption passphrase may be changed:

The un-mounting should also clear the keyring, to check the user’s keyring or clear it manually:

Auto-mounting

Different methods can be employed to automount the previously defined user-mount in /etc/fstab on login. As a first general step, follow point (1) and (2) of #Auto-mounting.

Then, if you login via console, a simple way is to specify the user-interactive mount and umount in the user’s shell configuration files, for example Bash#Configuration files.

The factual accuracy of this article or section is disputed.

Another method is to automount the eCryptfs directory on user login using pam_mount. To configure this method, add the following lines to /etc/security/pam_mount.conf.xml :

Please prefer writing manually these lines instead of simply copy/pasting them (especially the lclmount line), otherwise you might get some corrupted characters. Explanation:

the first line indicates where the user-based configuration file is located (here

/.pam_mount.conf.xml )

the second line overwrites the default required mount options which are unnecessary («nosuid,nodev»)

the last line indicates which mount command to run (eCryptfs needs the -i switch).

Then set the volume definition, preferably to

«noroot» is needed because the encryption key will be added to the user’s keyring.

Finally, edit /etc/pam.d/login as described in the pam_mount article.

Optional step

To avoid wasting time needlessly unwrapping the passphrase you can create a script that will check pmvarrun to see the number of open sessions:

With the following line added before the eCryptfs unwrap module in your PAM stack:

The article suggests adding these to /etc/pam.d/login , but the changes will need to be added to all other places you login, such as /etc/pam.d/kde .

Usage

This article or section needs expansion.

— point to the above «Setup & Mounting» section for how to mount and unmount [this section here will cover all other (i.e. setup-independent) usage info]
— reference ecryptfs tools not used/mentioned in the prior sections (e.g. with a short link to the online manpages and mention of the other tools usage, as it seems useful (not covered yet are, e.g. ecryptfs-stat, ecryptfs-find, ecryptfs-rewrite-file.)
— mention the options to share an encrypted folder between users and to place non-encrypted files or folders in the encrypted container («pass-through») (references for the points: [6] and (maybe) [7])

Symlinking into the encrypted directory

Besides using your private directory as storage for sensitive files, and private data, you can also use it to protect application data. Firefox for example has an internal password manager, but the browsing history and cache can also be sensitive. Protecting it is easy:

Removal of encryption

There are no special steps involved, if you want to remove your private directory. Make sure it is un-mounted and delete the respective lower directory (e.g.

/.Private ), along with all the encrypted files. After also removing the related encryption signatures and configuration in

/.ecryptfs , all is gone.

If you were using the #Ubuntu tools to setup a single directory encryption, you can directly follow the steps detailed by:

and follow the instructions.

Backup

If you want to move a file out of the private directory just move it to the new destination while

/Private is mounted.

With eCryptfs the cryptographic metadata is stored in the header of the files. Setup variants explained in this article separate the directory with encrypted data from the mount point. The unencrypted mount point is fully transparent and available for a backup. Obviously this has to be considered for automated backups, if one has to avoid leaking sensitive unencrypted data into a backup.

You can do backups, or incremental backups, of the encrypted (e.g.

/.Private ) directory, treating it like any other directory.

Further points to note:

• If you used the Ubuntu tools for #Encrypting a home directory, be aware the location of the lower directory with the encrypted files is outside the regular user’s $HOME at /home/.ecryptfs/$USER/.Private .
• It should be ensured to include the eCryptfs setup files (located in

/.ecryptfs usually) into the regular or a separate backup.

If you use special filesystem mount options, for example ecryptfs_xattr , do extra checks on restore integrity.

Known issues

Mounting may fail on a remote host when connecting via Mosh

This is a known issue of Mosh server, which does not keep the eCryptfs /home directory mounted.

Источник