# Runtime home encryption

## devilheart

Hello everyone,

I'm trying to encrypt my home folder and I am not really satisfied with my current setup. I have an encrypted partition mounted on /home and I followed the instruction for dm-crypt found on the wiki. Now, it asks for the key every time I reboot the computer and this could be sufficient because I am the only user.

Now, I would like to have additional security. I want the partition (or $HOME) to be encrypted whenever I lock my fvwm session with xscreensaver. This step should not affect the programs that are currently running (usually, a browser, skype and many xterms).

Is this possible?

----------

## szatox

No, it's not.

You either have the key loaded in RAM or you don't. If you do, your encrypted volume is "open" and any program allowed by kernel can access it. If you don't, it's "closed" so the kernel itself will not understand its content.

There is no way to only allow already running programs to access some bits of your data.

----------

## Sadako

It's not actually entirely impossible, just not easy and probable impractical.

dmsetup/cryptsetup support suspending and resuming device mapper targets, which would block all IO to the /dev/mapper/ device in question, remove the mapping, and require the luks passphrase to resume.

How userland apps would react to this is another thing, they should just "block" and be unusable until it`s resumed, but you`d need to test it first.

The awkward part is how to actually resume (and suspend for that matter), can be done easily enough if you switch to vt and log in as root, but any kind of integration with xscreensaver would be non-trivial.

At least just /home would be much easier than suspending an encrypted root directory, which would require a ramdisk or similar to get working.

----------

## frostschutz

I moved away from xscreensaver a long time ago because it kept screensaving while mplayer was running and such things...

So instead I use xautolock which basically handles the timeouts and lets you run any program to lock the screen (alock, or back to some screensaver after all, ...). It also runs a program to notify you of impending lock (xeyes in my case) so if you're idle reading a webpage you see those eyes pop up and click them away and avoid unnecessary screen lock that way.

In my fluxbox startup scripts it looks like this:

```

xautolock -time 5 -locker 'alock -auth passwd -bg blank' \

          -notify 10 -notifier 'killall xeyes; xeyes' \

          -corners +0-0 -cornerdelay 10 -cornerredelay 10 \

          -secure &

```

You could do that and run a locker script that does luksSuspend before alock, and do a prompt with zenity or whatever to luksResume afterwards.

 *Quote:*   

> How userland apps would react to this is another thing, they should just "block" and be unusable until it`s resumed, but you`d need to test it first.

 

Some programs might complain (if they have a separate writer thread and timeouts). You might also trigger a ton of race conditions (writes are usually instant and unlikely to race, but with luksSuspend they'd pile up and interfere with one another). On the other hand since ALL reads/writes will block, chances are a good number of programs will simply freeze forever. (That shell script in your home supposed to be doing the unlocking will freeze the same way...)

It's supposed to be used when the system goes into suspend as a whole so there is not much time between luksSuspend/luksResume.

If you trust your screen locker you could luksSuspend only after the locker itself quits. Thus while the screensaver is running, programs can still work normally (might be important, if you're re-encoding videos or whatever takes long and needs I/O to work while user is in screensaver limbo) but you'd still need to provide additional credentials after unlocking the screen.

Another snag is that these luksSuspend/Resume commands obviously have to be run as root, so you have to provide sudo permissions for that, and thus install yet another program that gives root permissions if not properly configured.

----------

## devilheart

Thank you all for the answers. Maybe dm-crypt is not the best tool to achieve this goal. Essentially, this is my office pc. When I am not here (I may be out for a coffe, lunch or a meeting in the toilet room), I would like that $HOME is unaccessible to anyone (sshd is not running), even root (he might login through CTRL+ALT+F1)

----------

## Akkara

Would it work to have a subdirectory of your home subject to this tighter encryption scheme?

Two partitions, two encryptions (can probably share the same key), one mounted on /home/you as currently done, the other then mounted on /home/you/subdir.  Slightly more annoyance (having to enter the PW twice after boot / sign-in).  But maybe it does what you need.

All the "." files will stay accessible which should alleviate most of the causes of hiccups in the window manager and other applications.  Only the more sensitive things go away when you do.  If those are being edited, that's probably OK, since the files shouldn't be getting touched unless you try to save or open (turn off any auto-save to be sure).  But if there's a download in progress to that area, that won't work so well.  Also the security won't be perfect: your browser's cache is in the "."-file area and will remain accessible to someone with root (unless you symlink it elsewhere).  So it depends on whether your most sensitive stuff can be partitioned in this way.

----------

## devilheart

Well, this is a solution worth looking into. Beside the usual ~/documents directory, the most important thing I have to protect is ~/.ssh

----------

## Sadako

I haven't played with it myself yet, but ext4 supports transparent per-directory encryption, maybe that'd be a better fit for your needs?

----------

## Roman_Gruber

 *devilheart wrote:*   

> 
> 
> I'm trying to encrypt my home folder and I am not really satisfied with my current setup. 

 

I suggest you encrypt / like i did with an unencrypted boot. The disc layout is according ot the gentoo handbook,  only / partition differs with a custom kernel + initramfs.

Else you have tmp files lying around with your user data.....

e.g. not deleted print jobs (yes cups does not delete finished or unfinished print jobs), tmp files and others.

sadly recently there are several folders which contain privacy related data.

--

Leaving a running box unantened with a screensaver lock is not the best idea anyway.

--

when you want security i would not use "skype" for obvious reasons

any software which runs and listens to a socket is a risk, espeically microsoft binaries

----------

