5

My wife and I are sharing a laptop running Ubuntu 12.04 LTS and I would like to encrypt the Home folder of each of us while still maintaining access by the other.

The encryption part using eCryptfs is simple enough but adding a second user is apparently not well documented. A shared encrypted folder would be possible but I think sharing the whole Home folder would be simpler and better supported by the community at large.

I read hints that you could add keys to the ecryptfs kernel keyring but the directions I found are far from being clear even if I describe myself as a power user.

3
  • possible duplicate of Sharing my home folders with other users on the same PC Feb 11, 2014 at 19:53
  • 1
    I read your suggestion but my need is for the data to stay encrypted so the answer there does not apply in my case. Thank you anyway !
    – Yves
    Feb 11, 2014 at 19:57
  • 3
    So no, it's not a duplicate, as that question does not address encrypting the shared folder at all.
    – Olli
    Feb 11, 2014 at 20:11

2 Answers 2

0

I thought this would be similar to LUKS with pam_mount using one home partition for all users (I don't know if that can be done or would be a good idea using LUKS) or using separate partitions for each user, which in case of LUKS would be more cumbersome. Reading the FAQ having both users being logged in sould be sufficient, or so it seems:

Once one user can access an eCryptfs file, any users with permission can also access the file. Should not eCryptfs require all users to have the key in order to access the files?

eCryptfs deliberately makes no attempt to re-implement the discretionary and mandatory access control mechanisms already present in the Linux kernel. eCryptfs will simply require that a File Encryption Key (FEK) be associated with any given inode in order to decrypt the contents of the file on disk. This prevents an attacker from accessing the file contents outside the context of the trusted host environment; for instance, by removing the storage device or by booting a live CD. This is the only type of unauthorized access that eCryptfs is intended to prevent.

Once eCryptfs has associated that FEK with the inode, it does not impose any additional restrictions on who or what can access the files, deferring to the standard user/group/other permissions, capabilities, SE Linux type enforcement, and so forth to regulate access to the files. eCryptfs maintains no pedigree regarding how the FEK found its way to the inode, so it has no way of knowing that any particular UID should or should not be able to open the file, nor should eCryptfs do such a thing.

Having eCryptfs impose additional access control onto the decrypted file contents in a trusted host environment would provide no additional security while introducing unintended usability issues. For instance, a user may wish to share his decrypted files with certain other users on the system without having to share his key with them or add their keys to a set of keys wrapping the inode's FEK. Users expect to be able to accomplish such a task via users, groups, capabilities, and types, and eCryptfs defers access control decisions on trusted host environments to these existing access control mechanisms.

You can find the complete FAQ in /usr/share/doc/ecryptfs-utils/ecryptfs-faq.html or online.


Another workaround would be to use an eCrypfs folder outside the users home folders that can be shared and that has a single password that the users can share (working around that both users would have to log into their accounts).

3
  • I'm testing as you are suggesting. Will see if this works for us.
    – Yves
    May 14, 2014 at 13:54
  • @Yves were you able to make this work?
    – Chuim
    Apr 29, 2016 at 14:13
  • 1
    @Chuim : no, in the end, we have used the built-in NAS in our Internet box instead.
    – Yves
    May 3, 2016 at 14:55
0

You can accomplish this pretty easily using Samba. It should take about five or ten minutes to get configured. However, please note that both users would need to be logged in for their encryption keys to be available for Samba to use. This won't work in a situation where you want one user to be able to access the other user's files while they are not logged in.

  1. Install Samba (if you don't have it installed)

    sudo apt-get install samba

  2. Add Samba users for the two Linux users (for this example they will be tom and sally)

    sudo smbpasswd -a tom sudo smbpasswd -a sally

  3. Open the Samba config file in a text editor /etc/samba/smb.conf

    sudo nano /etc/samba/smb.conf

  4. Add your share definitions near the bottom of the file. (Don't use the [home] share definition in the file already, as it won't allow you to use the necessary "force user" setting. See the note below about why "force user" is needed.)

    [tom] comment = Tom's home folder path = /home/tom guest ok = no browseable = yes read only = no valid users = tom, sally force user = tom

    [sally] comment = Sally's home folder path = /home/sally guest ok = no browseable = yes read only = no valid users = tom, sally force user = sally

  5. Save your changes, then restart the Samba server to be sure your new settings get applied. I use these three commands, but it might be more than is necessary.

    sudo samba restart sudo service smbd restart sudo service nmbd restart

  6. (Optional) By default, Samba will advertise your shared folders on the network. You can prevent this in a number of different ways. In the smb.conf file you edited above, you could set the allowed interfaces to only allow 127.0.0.1 (which means "this computer"). This can be set globally (in the Networking section of smb.conf) or you can set it individually on each share you want to restrict.

    interfaces = 127.0.0.1

If everything worked properly, you should be able to see your home folders listed in the Network section in your file browser (either your computer will show up as a network device, or you will find the folders in the "Windows Network" folder). When you first connect to the shared folder, you will be prompted to enter your Samba username and password, but you can avoid this in the future by having the file browser remember these for you.

Note: "Force user" causes file operations to be executed as the specified Linux user, regardless of who the logged in Samba user is. This means that when Sally writes a file to Tom's shared home, she is actually writing it as the Linux user tom. If you didn't use "force user", Sally would get an "NT_STATUS_ACCESS_DENIED" error (since Sally's Linux user cannot access Tom's encrypted home).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .