[kde-linux] Re: Password protect one folder?

[Duncan]

Werner Joss posted on Thu, 20 Jan 2011 16:42:45 +0100 as excerpted:

> Am Donnerstag, 20. Januar 2011, um 01:08:13 schrieb Dale:
>> I'm not sure what program does this but in mine, if I right click on a
>> file or directory in Konqueror, I can select to encrypt it in the
>> actions part of the menu.  I have done this before and it does work.  I
>> think it uses Kgpg but not sure.  I know I use the same password I gave
>> it.
> 
> right, konqueror/dolphin use the kgpg-kpart for this.
> nice feature, but not ecactly what the OP was asking for,
> as you always have to encrypt/decrypt yourself (hence,
> no automatic encryption when leaving the computer).

Yes.

The feature asked for isn't provided by kde (a thin GUI and apps suite, 
aka desktop environment, the original meaning of the de in kde, running on 
a base graphical layer, traditionally X as in xorg, running on a lower 
level OS, consisting of the kernel, like Linux, base userspace apps/
libraries, like the GNU libc and tools, and init system, like sysv init, 
upstart, etc), but rather by the OS.

One way to do it would be to use the Linux kernel's encrypted filesystem 
abilities along with userspace helpers, to create an encrypted filesystem, 
which you can then mount on a specific mountpoint in the existing 
filesystem.  It asks for a password when mounting the filesystem, and 
depending on configuration, would unmount it after an idle time and/or 
when the system goes into suspend.

It's worth noting that if your system has swap, some of the unencrypted 
data might be swapped out, and if there's a crash (consider a deliberate 
one like pulling the plug/battery), it could be recovered from swap.  To 
prevent this, Linux has an encrypted swap capacity as well.

It's also worth noting that it may be possible for an attacker to trigger 
a crash, then immediately reboot into a recovery OS that might try to scan 
the computer's memory itself.  The unencrypted data might still be there 
after a crash, especially if the machine wasn't powered off.  There are 
technical methods that can be used to mitigate this as well, but I don't 
believe mainline Linux or for that matter, mainline hardware, supports 
them.  This is going a bit beyond the practical to defend against for most 
people, but it's worth keeping the possibility in mind.

On the flip side, as another user mentioned, there's the much easier but 
less protective method of simply setting the ownership of certain 
directories to a different user, with permissions set so the normal user 
can't read them.  This protects from normal runtime access without a 
password and is reasonably trivial to setup, but it should be kept in mind 
that the data isn't encrypted, simply protected via ownership and 
permissions.  As such, root can always read it so if someone gets root, 
either normally or via a root exploit or simple reboot and access from a 
liveCD/USB/whatever, the files won't then be protected.  But if normal 
runtime protection is all you're worried about, this is the easiest to 
setup since it's using existing filesystem ownership and permissions that 
the system uses routinely for all sorts of other purposes already.  I use 
this method here, on my main machine (my netbook deliberately has nothing 
private on it, save for the ssh keys to access it remotely, and if someone 
already has it in their possession, that's of no further value), to 
protect certain data, but I know it's worthless as a protection from 
someone able to get root, either by reboot to a recovery disk, or via root 
exploit.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman