Never had the privilege to deal with Datapower on Linux. Though it looks very interesting.

@black3dynamite said in Cannot boot to LUKS encrypted drive on Ubuntu - freezes after unlocking drive:

@travisdh1 Is it possible that AppArmor installed by default on all ubuntu installation? Having AppArmor and SELinux both active can cause problems.

I'd love to hear a bit more about apparmor. I am not familiar with it at all. This should be a new thread.

@stacksofplates said in Encryption FS on the Cloud and Remote SSH:

To play devil's advocate, if you're using LUKS the data is encrypted in transit also. So it's not just at rest.

I can't remember off of the top of my head, but you might need FIPS mode enabled for dm-crypt to encrypt in motion as well. I'm lazy and don't feel like looking it up.

@thwr said in Kickstart with LUKS:

@scottalanmiller said in Kickstart with LUKS:

@thwr said in Kickstart with LUKS:

@thwr said in Kickstart with LUKS:

But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.

Ah, sorry, misunderstood your posting in the first place. Well, that's chicken-egg. You can either have it decrypt automatically or not. If going for automatic decryption, we have to make sure the machine can't decrypt e.g. when it gets stolen or sold.

For this, storing the key on the host alone, even with TPM, may not be enough (don't know enough about TPM at this point. Sealing to system state seems quite safe, but...). Thus, we need to bring in another factor. Let's call it "location awareness", e.g. pulling the actual key from the network and TPM stores just something to authenticate against the "key server". Server offsite -> no decryption.

Past boot, it is up to you to secure the server by traditional means. Strong passwords, no or strongly secured RS232 TTY and so on.

Exactly, something externally has to trust that the system is where it is supposed to be physically so that it will release the key. We considered using this but decided that security trumped downtime and kept the system requiring human intervention and just accepted large downtimes in the event of a reboot.

Agree, downtime due to a misconfiguration, some failure on the network or the key server would be an issue. What if we look at some back approach: If some removeable storage with a key is present at boot, LUKS will use this key. Otherwise, it tries to pull it from the key server as described above? Should be pretty solid and a backup is in place (key on USB stick) in case something goes south.

This surely is an approach for environments requiring a very high level of security, but I like the idea.

I've seen places do that, pop in a key and use that, but you have to trust that people will remove it immediately and store it somewhere.