Firefox User Profiles No Longer work in encrypted folders or partitions??

[StewartM]

I've just upgraded my desktop from 8.04 to 10.04. I'm using Scramdisk 2.02.

Previously, I had placed my firefox user profile in an encrypted Truecrypt container file created under Scramdisk. I had done so by creating a new profile in firefox's profile manager. This had worked in previous versions (and it still works with 9.10 on my laptop).

But when I tried to access my previous profile when first opening firefox, I got the error message "cannot use profile 'x' because it is in use".

I have tried the following workarounds:

a) creating a new profile in an encrypted container;
b) creating a new profile in an encrypted container with a different filesystem (FAT32 instead of ext3);
c) dragging an existing and working firefox profile created under the ./mozilla/firefox default directory into an encrypted container and linking back to it;
d) dragging the entire ./mozilla/firefox folder into an encrypted container and linking back to it on the main directory tree;
e) creating an EncFS folder instead of a TrueCrypt container and creating profile inside of it.
f) draging an already-created and working firefox profile (created under ./mozilla/firefox) into an ecrypted EncFS folder and linking back to it.

And yet, each time I get the same error message.

Note, if I create a new profile under the ./mozilla/firefox directory and replace all the default files with those from a profile folder from an encrypted folder, it starts normally. But there I lose the advantages of encryption.

I also have tried my other programs that I have linked to encrypted folders--Pan, Pidgin, Evolution, plus other folders I have moved (./thumbnails, ./gnupg, ./openofficeorg, ./wine, ./yahoorc). These all work as they did previously. I can open my containers, view and create new files in them, so it's not obviously a permissions issue.

So is there anything about Firefox that doesn't like encrypted folders or partitions? I also note that firefox takes a lot longer to start than it used to.

StewartM

[bodhi.zazen]

Firefox works fine with the default encryption tools, LUKS for whole disk encryption and ecryptfs for an encrypted home.

Is there some reason you do not want to use the default tools ?

Otherwise the tools you mention are both third party, you may need to try the mailing lists or forums for those projects (if no one here knows an answer).

[StewartM]

Firefox works fine with the default encryption tools, LUKS for whole disk encryption and ecryptfs for an encrypted home.

Is there some reason you do not want to use the default tools ?

Otherwise the tools you mention are both third party, you may need to try the mailing lists or forums for those projects (if no one here knows an answer).

To answer your first question--I have been using Scramdisk, using Truecrypt containers, since 7.04. This is the first time it's broken. Everything else but firefox running from inside the container works as normal.

Scramdisk has been well maintained. The only problem so far with 10.04 is that Scramdisk currently requires 2.6.32-22 generic, and it is broken by the kernel that came by default with with the new upgrade--2.6.32-24 generic. When Scramdisk was installed, it installed the earlier kernel, but going back a step degrades my video performance (so I run in low-graphics mode). I've emailed the developer about this, and if past experience is any guide he'll respond by issuing a recompiled version that works with 2.6.32-24.

To answer you second question--both Truecrypt and EncFS *are* supported by Ubuntu--or at least they are supported by the community, as these programs are all found in the repositories. Truecrypt is implement by Easy Crypt and GDecrypt, where EncFS folder encryption is implemented using Cryptkeeper. I was using Cryptkeeper to create the encrypted EncFS folder in this instance.

I would have thought that someone would be doing something similar, as I asked as a raw newbie 3 years ago how to direct mail and other folders to an encrypted container on this same forum, and received answers how to do it.

http://www.ge.ubuntuforums.org/showthread.php?t=554741&


As for using the default tools, as I understand it, requires moving everything off the drive and doing a clean install to set up an encrypted /home directory using the Alternative CD. Is that right?

Also, when this idea was being floated in development, I recall that the passphrase to one's /home directory encryption would be the same as the login passphrase. *If* that was so it seemed to me that someone could walk up to your machine, boot from a live CD, then force a change of one's login passphrase as root in recovery mode. Then one has complete access to everything as one would be able to log in as that user. That would defeat the whole purpose of having any encryption would it not?

With an encryption passphrase with a separate program that's separate from the login, by contrast, there's no way for such an attacker to access the materials inside the encrypted folders or containers. They can delete the account and all the files, to be sure, but they can't access anything. That seemed to me the safer route.

Please correct me if my perceptions are wrong about this. It was these concerns, plus the additional work that doing an installation from scratch involved, which kept me from going the encrypted /home route.

As for the whole-disk encryption option--that defeats the purpose of having a multi-user system. Either it becomes a single-user system, or you share a passphrase with someone (bad idea).

StewartM

[bodhi.zazen]

If you wanted to use LUKS, yes you would need to back up your data and perform a fresh install with the alternate CD.

LUKS supports up to 8 passwords (if you have multiple users and do not want to share a password).

If you use ecryptfs to encrypt your $HOME directory , by default, it uses you login to decrypt $HOME.

BUT, you can not simply change a users password as root or with a live CE and access the data, that is a misunderstanding on your part. Try it in a VM or a test installation and see for yourself

With ecryptfs a user has to change his or her password with the graphical tools or via the commmand line via an additional step. There are several page on an encrypted home on Ubuntu if you wish.

http://bodhizazen.net/Tutorials/Ecryptfs

You can access the encrypted $HOME from a live CD, if you have the information you need :

http://blog.dustinkirkland.com/2009/...home-from.html

Hope that helps your understanding. I do not know the answer to your original question / problem with firefox.

I have not used truecrypt in a while but my impression is that it is less and less compatible with Ubuntu over time, and your post re kernel and video problems reinforce that impression.

FYI, if your issue is somehow one of cross platform, there are applications to mount a LUKS partition in Windows and I believe OSX.

FreeOTFE - Windows LUKS

As you can probably guess, I use LUKS and have not run into any problem with kernels, video, or really any problem at all.

[FuturePilot]

As for using the default tools, as I understand it, requires moving everything off the drive and doing a clean install to set up an encrypted /home directory using the Alternative CD. Is that right?

No http://blog.dustinkirkland.com/2009/...directory.html

Also, when this idea was being floated in development, I recall that the passphrase to one's /home directory encryption would be the same as the login passphrase. *If* that was so it seemed to me that someone could walk up to your machine, boot from a live CD, then force a change of one's login passphrase as root in recovery mode. Then one has complete access to everything as one would be able to log in as that user. That would defeat the whole purpose of having any encryption would it not?

No http://blog.dustinkirkland.com/2009/...tfs-works.html

[StewartM]

Thanks to both of you for clearing up my misunderstanding.

Just for the sake of simplicity, would it be possible to set up the ./Private directory using Ecryptfs, and then try syslinking the ./mozilla/firefox/user profile directory to that? I assume that was the original purpose of such the ./Private folder in 8.10. (Although I can't see why that would be so different than what I had been doing with my earlier attempts).

I should also say that this is not a sudo user (I adhere to the habit of only using my sudo user for administration and not ordinary work). I assume that the command ecryptfs-setup-private does not need sudo privileges?

As for the encrypted /home option, that would require freeing up more disk space than I currently have, even after doing a lot of disk cleaning. There's probably a workaround for that, but that would be second choice.

Once again, thanks.

StewartM

[FuturePilot]

Just for the sake of simplicity, would it be possible to set up the ./Private directory using Ecryptfs, and then try syslinking the ./mozilla/firefox/user profile directory to that? I assume that was the original purpose of such the ./Private folder in 8.10.

Yes, that is indeed how it originally worked with 8.10. It was later expanded to be able to encrypt your entire /home/$USER directory.

I should also say that this is not a sudo user (I adhere to the habit of only using my sudo user for administration and not ordinary work). I assume that the command ecryptfs-setup-private does not need sudo privileges?

No, it can be run as a non-sudo user.

(Although I can't see why that would be so different than what I had been doing with my earlier attempts).

The problem with scramdisk is that it's a third party kernel module which is precompiled against a certain kernel version. When the kernel ABI changes, it breaks scramdisk. You would have to recompile the kernel module whenever the ABI changes. It would be better if scramdisk used DKMS to automatically recompile it whenever the kernel ABI changes. You wouldn't run into this problem using built-in tools like ecryptfs or LUKS.

[rookcifer]

Also, when this idea was being floated in development, I recall that the passphrase to one's /home directory encryption would be the same as the login passphrase. *If* that was so it seemed to me that someone could walk up to your machine, boot from a live CD, then force a change of one's login passphrase as root in recovery mode. Then one has complete access to everything as one would be able to log in as that user. That would defeat the whole purpose of having any encryption would it not?

That's the case for EncFS, but not for the better LUKS option. LUKS will do whole disk encryption, which means that, obviously, the password used will be different from that of the user account. (LUKS will also do container encryption if you need that). LUKS is a better option for Linux than Truecrypt since Truecrypt was specifically written with Windows in mind. Truecrypt still cannot do WDE on Linux, plus TC has that weird home brew license.

As for the whole-disk encryption option--that defeats the purpose of having a multi-user system. Either it becomes a single-user system, or you share a passphrase with someone (bad idea).

Hmm, well obviously if you trust someone enough to use your system you should trust them enough to decrypt it in order to use it. Or, if you prefer, you can create separate partitions and encrypt them with different passphrases. BTW, LUKS will allow 8 different passwords to be used for the same container. This is so that if someone should no longer need access you can delete their password without having to change your own. This is good in work environments where there might be turnover.

[FuturePilot]

That's the case for EncFS,

You mean Ecryptfs? That's not the case with Ecryptfs. Even if someone changed your login password with say the root account, that's all they can change. They still couldn't access your encrypted data because it will still be encrypted with the salted passphrase created from your old password.

[rookcifer]

You mean Ecryptfs? That's not the case with Ecryptfs. Even if someone changed your login password with say the root account, that's all they can change. They still couldn't access your encrypted data because it will still be encrypted with the salted passphrase created from your old password.

I should have been more specific. I was only responding to this statement:

Also, when this idea was being floated in development, I recall that the passphrase to one's /home directory encryption would be the same as the login passphrase.

It's true that ecryptfs uses the user password as the volume key. It's also true that the developers aren't stupid and don't allow the volume password to change each time the user password changes.

As for encryptfs and EncFS, they are essentially the same thing except ecryptfs runs in kernel mode while EncFS runs in userspace. But, yes, you're right, I should have said ecryptfs since that is what Ubuntu uses. I also happen to hate it and never recommend such encryption techniques. Block device encryption is much cleaner, imo.