I was hoping any keylogger is loaded AFTER you type the password/passphrase, in other words you would boot a live CD on a diskless pc, then enter the passphrase to mount one container out of a 100, then browse the internet, then get infected, then the malware can only see the one container but not the other 99 containers.

Unless it steals the passphrase from ram from my little binary executable. Containers would have different keys but the same passphrase so it is only typed once, so keyloggers cannot steal it.

If an SElinux setup makes it impossible to steal the passphrase from ram, that's what I need. But SElinux seems way too hard to set up.

Does an SElinux live CD exist, with instructions for editing the live CD to add a browser, truecrypt-like software and ssh?

The best instructions I know are at: http://selinuxproject.org/page/Main_Page
and http://billauer.co.il/selinux-policy-module-howto.html

No it isn't easy yet, but it is the most complete.

The passphrase is no longer needed once the key has been derived from container header and passphrase. Good encryption software should 1) allocate the memory for the passphrase in such a way that is is never swapped out, 2) Overwrite the memory for the passphrase once it is no longer needed.

I can only guess that cryptsetup-luks or truecrypt do it in the right way, more research is required to be sure. I recommend not working with the passphrase in own scripts - you only add more copies of the passphrase, which are neither swap-protected nor sanitized after usage. You can call the crypto backend in your script and display it's password prompt, though. That way, your script process never keeps the passphrase in own memory.

The key is another beast: It has to remain in memory the whole time the container is open, because encryption and decryption of blocks occur all the time. If your 100 containers are created independently (and not copied from each other), all of them have a different key and one compromised container does not compromise the others. That is, if it is compromised by getting the key.

Some cues:

Hardened Kernel grsecurity.net - Trusted Path execution, sanitize freed memory, AppArmor/SELinux
Firefox with noscript addon, and webgl disabled in about:config

^That way it should be very, very difficult for code from the web to be even executed in the first place. Always keep the software up to date, best in a still supported long-term version. Especially browser and kernel.

Thanks, and please have another look at my last edited post, the passphrase is held in ram in order to avoid typing it more than once which would expose it to a keylogger. It is needed because the keys generated from it are deliberately different for each container.

Ah sorry I did not notice this detail. But I think a keyfile instead of a passphrase would be a better option in that case. Maybe put the key file in a new container protected with an own passphrase. Once opened, the keyfile is accessible for the work with the 100 containers. Neither passphrase nor keyfile remain in application memory.

That's what you need to do: access is controlled by a unique, cryptographically-generated key. Use of the key, then, is controlled by a passphrase which must be used to decrypt the key. (Or, perhaps this latter step is optional.)

The host, perhaps using LDAP on its end for key-management, identifies each unique key and individually grants (or denies) access to each one. The host might know other things, such as the IP-address that the client will be coming from. In any case, you must possess both the key and the means to use it. If the client machine is compromised, the specific key that it is known to have held is promptly revoked by the host. (When "Eve" tries to use the now no-good key thereafter, you'll also know where she's coming from, and that it must be Eve.)

Thing is, we do not trust any remote host. This is why client-side encryption is preferred.

We do not trust our client either, once it has been infected.

Hopefully part of the client can be protected, ie most of the 100 containers and the passphrase that opens them all.

When would you be able to load malware that steals passwords from RAM, but not malware that logs keystrokes?

Malware cannot log keystrokes because you never type passphrase with malware loaded, only when you boot the live CD, and the live CD has been edited to never allow internet access before the passphrase has been typed.

Doesn't prevent the malware from having gotten in before the CD was made.

Maybe the live CD can be made in a live CD session.

I'm pretty sure that this would prevent people stealing the password from RAM. If you use cryptsetup it should handle the password correctly so it doesn't stay in RAM, and mounting an encrypted partition does not leak unencrypted data to RAM, AFAIK.

I'm mostly concerned about keeping the password in a bash variable, then they could use strace to find it because bash isn't designed to be particularly secure with its variables.

Yeah, seriously. Are you really assuming that the "container" is the only place where malware can be loaded from?

Also, if I'm understanding you right, then all you need to do is use memset to zero out the variables in your little binary executable that contain the password, right after your executable opens the container.

They won't steal the passphrase but they will steal all the data, if it's only one container.

If it's more than one container, with different keys each container, then the passphrase has to stay in ram or you type it over and over every time you open yet another container.

You want to work with 3 containers, say, in a live CD session, out of 100, so only these 3 are exposed to spying malware.