Solution #2:
Provide graphical tool for managing the encryption of existing home directories
Some users may decide they need to switch on/off the use of encryption for their home directory. That is, they may not have enabled encryption to begin with, but now need it; or, they may have it enabled, but now decide they don't want it.
Enabling encryption during a fresh install is easy for a single account, but turning it on later means sending the user to the command line. Same with disabling it later on.
I suggest the ability to switch on/off encryption for one's home directory be an option in the "User and Groups" program for the properties of the account in question (that is, System -> Administration -> Users and Groups -> Properties).
I would have a check box under the existing "Don't ask for password on login" option that says "Encrypt home directory". Checking the box would encrypt the user's home directory while un-checking the box would turn it off (that is, decrypt the contents).
Also, I would require the password of that account to be entered in order for either change to take effect. That way someone with sudo privileges can't toggle encryption on/off for user accounts without knowing their passwords.
Some users may decide they need to switch on/off the use of encryption for their home directory. That is, they may not have enabled encryption to begin with, but now need it; or, they may have it enabled, but now decide they don't want it.
Enabling encryption during a fresh install is easy for a single account, but turning it on later means sending the user to the command line. Same with disabling it later on.
I suggest the ability to switch on/off encryption for one's home directory be an option in the "User and Groups" program for the properties of the account in question (that is, System -> Administration -> Users and Groups -> Properties).
I would have a check box under the existing "Don't ask for password on login" option that says "Encrypt home directory". Checking the box would encrypt the user's home directory while un-checking the box would turn it off (that is, decrypt the contents).
Also, I would require the password of that account to be entered in order for either change to take effect. That way someone with sudo privileges can't toggle encryption on/off for user accounts without knowing their passwords.
Solution #3:
Provide an encryption key master/policy enforcement tool
Encryption isn't just important to end-users, but it is important to businesses, too. Especially if they have to comply with mandated data security policies, such as the Sarbanes-Oxley Act (see
http://www.soxlaw.com/), for which they have no say in the matter.
If Ubuntu is going to make inroads into these kinds of enterprise markets, there needs to be a management tool to ensure that an employee cannot encrypt their home directory without providing a means for another user (e.g., the primary sys admin for the company) to decrypt it (and yes, I know, a rogue user could always just use something like TrueCrypt, but this about meeting data security policy requirements).
Also, there needs to be a method for enforcing encrypted home directories.
I don't think either of these functions fits into the "Users and Groups" management application. So, maybe this is something best suited for integration into policykit?
Of course, such a tool should be protected in such a way that a user with local root privileges couldn't use it to gain access to the encrypted contents of other users on the system unless it is a key-master account.
Encryption isn't just important to end-users, but it is important to businesses, too. Especially if they have to comply with mandated data security policies, such as the Sarbanes-Oxley Act (see http://www.soxlaw.com/), for which they have no say in the matter.
If Ubuntu is going to make inroads into these kinds of enterprise markets, there needs to be a management tool to ensure that an employee cannot encrypt their home directory without providing a means for another user (e.g., the primary sys admin for the company) to decrypt it (and yes, I know, a rogue user could always just use something like TrueCrypt, but this about meeting data security policy requirements).
Also, there needs to be a method for enforcing encrypted home directories.
I don't think either of these functions fits into the "Users and Groups" management application. So, maybe this is something best suited for integration into policykit?
Of course, such a tool should be protected in such a way that a user with local root privileges couldn't use it to gain access to the encrypted contents of other users on the system unless it is a key-master account.
Solution #4:
Not only to 'Home' folder....
Written by
DrG the 10 Dec 09 at 08:58.
Another idea .---->
A better way is to implement an 'Encryption' option to the 'Permissions' tab (of the Properties Dialogue of files , directories and disks) , which encrypts
files , directories or disks with a password entered by the user ( or the login password - which should not ask password , for decryption , once the specific user logs in , as per choice), and encrypts the item , according to the algorithm selected by the user.
######
In karmic , home directory encryption is achieved through Cryptsetup . A tutorial is here
http://gentoo-blog.de/ubuntu/encrypted-home-and-swap-partition-on-ubuntu-9-10-k armic/
####
#-------------------
The Rationale , to a much less extent , can be achieved through nautilus.-->
Right click the desired directory, select 'Properties' , choose 'Permissions' tab ; set Permissions of 'Group' and 'Others' to 'None'(set the Owner as the user ) .( The drawback is that 'root' will be still able to access the content , so as other users with 'gksu nautilus' - so don't rely much on this until tracked ) .
Another idea .---->
A better way is to implement an 'Encryption' option to the 'Permissions' tab (of the Properties Dialogue of files , directories and disks) , which encrypts
files , directories or disks with a password entered by the user ( or the login password - which should not ask password , for decryption , once the specific user logs in , as per choice), and encrypts the item , according to the algorithm selected by the user.
######
In karmic , home directory encryption is achieved through Cryptsetup . A tutorial is here http://gentoo-blog.de/ubuntu/encrypted-home-and-swap-partition-on-ubuntu-9-10-karmic/
####
#-------------------
The Rationale , to a much less extent , can be achieved through nautilus.-->
Right click the desired directory, select 'Properties' , choose 'Permissions' tab ; set Permissions of 'Group' and 'Others' to 'None'(set the Owner as the user ) .( The drawback is that 'root' will be still able to access the content , so as other users with 'gksu nautilus' - so don't rely much on this until tracked ) .
Solution #5:
Extend the user managment utility of Ubuntu
Written by
xfuser4 the 15 Dec 09 at 12:37.
Extend the user managment utility of Ubuntu, to create users with encrypted home directories.
Extend the user managment utility of Ubuntu, to create users with encrypted home directories.
Solution #6:
Don't encrypt home folder but only parts of it and make key locations clearer
Written by
natschil the 20 Dec 09 at 19:11.
Currently, the whole home folder is encrypted, which is suboptimal for people, who want to keep private data but also run a lot of io operations, such as compiling software. Furthermore, keys are kept not only in /home, but also somewhere in /var, iirc, which is a pain if your system crashes and you try to mount the encrypted home directores. Therefore I think it would be more practical to have only part of the home folder encrypted.
Currently, the whole home folder is encrypted, which is suboptimal for people, who want to keep private data but also run a lot of io operations, such as compiling software. Furthermore, keys are kept not only in /home, but also somewhere in /var, iirc, which is a pain if your system crashes and you try to mount the encrypted home directores. Therefore I think it would be more practical to have only part of the home folder encrypted.
Solution #7:
Provide GUI with automated processes
Provide a simple, straightforward GUI that has a few basic steps. This would handle all the requirements for the average user. Expert users would still be free to use terminal to perform fancier functions.
I would envisage that the GUI would come installed by default on both the Live CD and a normal installation.
1. The GUI would have the following options. In all three cases, it would require Administrator rights (gksu) when not for your own home directory. It would have to allow looking at home directories on a different drive, e.g. when booting from a Live CD to recover from some problem.
(a) Synchronise password.
(b) Encrypt a home directory.
(c) Stop encrypting a home directory.
(d) View a home directory.
(e) Save recovery key on a file (e.g. USB drive).
Note: For changing the login password the normal way, I would want the system to automatically synchronise the home directory. Option (a) would be for when something goes wrong and recovery is required from the Live CD (a situation that I have encountered).
The options would work as follows. In all cases, prompt for Administrator access if not your own home directory. Naturally, there should be checks for nonsense requests, such as trying to encrypt a home directory that is already encrypted or trying to view a home directory that is already mounted (decrypted with ecryptfs).
(a) Synchronise password.
- Explain to the user what this option means (non-technical users may not realise that the password should match the login password).
- Prompt for:
* which home directory to change.
* its 32-character unlock key, which optionally can be a file from point (e). If already successfully mounted (e.g. the user's own home directory), then omit this step.
* the new (or current) login password.
- Change the password to the new one.
(b) Encrypt a home directory.
- Explaing to the user what this option means (specifically for non-technical users).
- Warn that backups should be taken first in case of problems.
- Prompt for:
* which home directory to change.
* the current login password (if possible, let the system validate this password).
- Display the 32-character unlock code and ask the user to save it safely away from his computer. Explain the importance of doing this. Provide the option of saving it as a file, e.g. on a USB drive -- see point (e). After the user has confirmed doing this...
- Encrypt the home directory (for the user's own home directory, set the mount points accordingly).
(c) Stop encrypting a home directory.
- Prompt for:
* which home directory to change.
* its 32-character unlock key, which optionally can be a file from point (e). If already successfully mounted (e.g. the user's own home directory), then omit this step.
- Stop encrypting the home directory (for the user's own home directory, modify the mount points accordingly).
(d) View a home directory.
- Prompt for:
* which home directory to view.
* its 32-character unlock key, which optionally can be a file from point (e).
- Mount the home directory.
- Display the mount point for the user.
- Open the mount point in Nautilus (or whatever default file management system is set for the installation).
(e) Save recovery key on a file (e.g. USB drive).
- Prompt for:
* which home directory.
* its 32-character unlock key, which optionally can be a file from point (e). If already successfully mounted (e.g. the user's own home directory), then omit this step.
* where to save the file (name and location). Clearly warn the user of the risks of keeping the file phsically near the computer. If the file already exists, warn about overwriting it.
- Save the 32-character unlock key in a simple text recovery file.
Provide a simple, straightforward GUI that has a few basic steps. This would handle all the requirements for the average user. Expert users would still be free to use terminal to perform fancier functions.
I would envisage that the GUI would come installed by default on both the Live CD and a normal installation.
1. The GUI would have the following options. In all three cases, it would require Administrator rights (gksu) when not for your own home directory. It would have to allow looking at home directories on a different drive, e.g. when booting from a Live CD to recover from some problem.
(a) Synchronise password.
(b) Encrypt a home directory.
(c) Stop encrypting a home directory.
(d) View a home directory.
(e) Save recovery key on a file (e.g. USB drive).
Note: For changing the login password the normal way, I would want the system to automatically synchronise the home directory. Option (a) would be for when something goes wrong and recovery is required from the Live CD (a situation that I have encountered).
The options would work as follows. In all cases, prompt for Administrator access if not your own home directory. Naturally, there should be checks for nonsense requests, such as trying to encrypt a home directory that is already encrypted or trying to view a home directory that is already mounted (decrypted with ecryptfs).
(a) Synchronise password.
- Explain to the user what this option means (non-technical users may not realise that the password should match the login password).
- Prompt for:
* which home directory to change.
* its 32-character unlock key, which optionally can be a file from point (e). If already successfully mounted (e.g. the user's own home directory), then omit this step.
* the new (or current) login password.
- Change the password to the new one.
(b) Encrypt a home directory.
- Explaing to the user what this option means (specifically for non-technical users).
- Warn that backups should be taken first in case of problems.
- Prompt for:
* which home directory to change.
* the current login password (if possible, let the system validate this password).
- Display the 32-character unlock code and ask the user to save it safely away from his computer. Explain the importance of doing this. Provide the option of saving it as a file, e.g. on a USB drive -- see point (e). After the user has confirmed doing this...
- Encrypt the home directory (for the user's own home directory, set the mount points accordingly).
(c) Stop encrypting a home directory.
- Prompt for:
* which home directory to change.
* its 32-character unlock key, which optionally can be a file from point (e). If already successfully mounted (e.g. the user's own home directory), then omit this step.
- Stop encrypting the home directory (for the user's own home directory, modify the mount points accordingly).
(d) View a home directory.
- Prompt for:
* which home directory to view.
* its 32-character unlock key, which optionally can be a file from point (e).
- Mount the home directory.
- Display the mount point for the user.
- Open the mount point in Nautilus (or whatever default file management system is set for the installation).
(e) Save recovery key on a file (e.g. USB drive).
- Prompt for:
* which home directory.
* its 32-character unlock key, which optionally can be a file from point (e). If already successfully mounted (e.g. the user's own home directory), then omit this step.
* where to save the file (name and location). Clearly warn the user of the risks of keeping the file phsically near the computer. If the file already exists, warn about overwriting it.
- Save the 32-character unlock key in a simple text recovery file.
Solution #8:
Add always "encrypt home folder" option in "users and group" panel
Written by
tanoloco the 12 Jan 11 at 09:05.
I think that the option "Encrypt home folder to protect sensitive data" might be always available on "Users and groups" panel because it can happen that there's no need to encrypt home during installation and then after some time it could be needed to encrypt a new user home folder.
I think that the option "Encrypt home folder to protect sensitive data" might be always available on "Users and groups" panel because it can happen that there's no need to encrypt home during installation and then after some time it could be needed to encrypt a new user home folder.
Propose your solution
Attachments
No attachments.
Duplicates
Comments
leoquant
(Idea reviewer)
wrote on the 7 Dec 09 at 08:44
You are of course aware of : ecryptfs-utilizes and the "ecryptfs-setup-private" setup?
You are asked first for your login password, enter your log in password. You will next be asked to "Enter your mount passphrase" [leave blank to generate one] , leave this blank (hit the enter key) and a random passphrase will be generated.
That is all there is to it. Any data you place in ~/Private will be encrypted in ~/.Private when you log off.
Fully automatic, and decrypted when login.
andruk
(Idea reviewer)
wrote on the 8 Dec 09 at 19:05
Again, agreed with AndrewLuecke.
Therefore I think it would be more practical to have only one part of the home folder nonencrypted. Something as a personal tmp folder nonencrypted and inside home(maybe symbolic link) folder.
ayeomans
wrote on the 12 Aug 10 at 12:47
Another reason for making this simple is when using auto-login. I've found it useful on a netbook to have an auto-login user for quick web browsing, etc. And then switch to a secure user if I need to access encrypted personal files.
(Have to remember to log off the secure user - just switching back to the auto-login user will leave the directories still mounted.)
Yfrwlf
wrote on the 12 Sep 10 at 20:18
Solution #1 has been implemented already, there is an option to encrypt a new user's home folder.
Solution #2, however, has not been. There is no way to manage the encryption of an *existing* user.
I think both things are needed, because it would be time-consuming to turn on encryption for a user after they have been created, if only solution #2 was implemented, so both solutions are needed.
We have solution #1 implemented, now we just need solution #2 implemented. For instance, I no longer need my home direction encrypted, but there is no easy GUI way to turn it off and it hampers my system performance somewhat.
tanoloco
wrote on the 13 Jan 11 at 13:40
if someone doesn't click on the "Encrypt my home folder" during a fresh new installation of Ubuntu Maverick, because it's not needed for the first user, then using the "Users and groups" panel under System > Administration menu there's no way to encrypt a second user's home folder because there's no option "Encrypt home folder to protect sensitive data" available to check when clicking the "add" button as you can find instead if you choose to encrypt the first user home folder during installation.
I think that the option "Encrypt home folder to protect sensitive data" might be always available on "Users and groups" panel because it can happen that there's no need to encrypt home during installation and then after some time it could be needed to encrypt a new user home folder.
Post your comment