Solved supporting an office of computers with full drive encryption
-
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
I do trust Windows, let's just assume that they aren't doing anything wrong. I still don't know how you access an encrypted location during logon so that Windows can load the profile. How are you accomplishing this?
You don't, you decrypt it before logging in. No matter what you do, encryption comes out to be a pain.
HOW? How are you decrypting before logon? This is what Mike wants to know.
Key is stored in the TPM. TPM/Bios/UEFI decrypts the drive in order to boot Windows before login.
This is not what Scott is talking about at all though.
I've not tested this, but any reason it can't work with just one partition like LUKS can?
No clue what LUKS is, but assuming a single partition, how do you do remote updates to an encrypted drive? I'm assuming it can't boot without a user there to type in a password.
We can encrypt home directories and still boot the machine. Why would it not be able to boot? The user data is on a separate drive. I'm lost as to why it wouldn't work.
I'm not talking about BOOTING, I'm talking about loading the user profile. In the case of Windows - how would you load a profile that's stored on an encrypted (still locked) partition? When you enter the username/password, the system tries to load the profile from D but can't becuase it's locked. But you can't unlock it until after you log in.
See the problem?
LUKS uses the users password to unlock the partition.
-
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
I do trust Windows, let's just assume that they aren't doing anything wrong. I still don't know how you access an encrypted location during logon so that Windows can load the profile. How are you accomplishing this?
You don't, you decrypt it before logging in. No matter what you do, encryption comes out to be a pain.
HOW? How are you decrypting before logon? This is what Mike wants to know.
Key is stored in the TPM. TPM/Bios/UEFI decrypts the drive in order to boot Windows before login.
This is not what Scott is talking about at all though.
I've not tested this, but any reason it can't work with just one partition like LUKS can?
No clue what LUKS is, but assuming a single partition, how do you do remote updates to an encrypted drive? I'm assuming it can't boot without a user there to type in a password.
We can encrypt home directories and still boot the machine. Why would it not be able to boot? The user data is on a separate drive. I'm lost as to why it wouldn't work.
I'm not talking about BOOTING, I'm talking about loading the user profile. In the case of Windows - how would you load a profile that's stored on an encrypted (still locked) partition? When you enter the username/password, the system tries to load the profile from D but can't becuase it's locked. But you can't unlock it until after you log in.
See the problem?
LUKS uses the users password to unlock the partition.
That would be awesome, and totally solve this problem - any know if Bitlocker can do this? I think @dafyre tried but it didn't work.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
I do trust Windows, let's just assume that they aren't doing anything wrong. I still don't know how you access an encrypted location during logon so that Windows can load the profile. How are you accomplishing this?
You don't, you decrypt it before logging in. No matter what you do, encryption comes out to be a pain.
HOW? How are you decrypting before logon? This is what Mike wants to know.
Key is stored in the TPM. TPM/Bios/UEFI decrypts the drive in order to boot Windows before login.
This is not what Scott is talking about at all though.
I've not tested this, but any reason it can't work with just one partition like LUKS can?
No clue what LUKS is, but assuming a single partition, how do you do remote updates to an encrypted drive? I'm assuming it can't boot without a user there to type in a password.
We can encrypt home directories and still boot the machine. Why would it not be able to boot? The user data is on a separate drive. I'm lost as to why it wouldn't work.
I'm not talking about BOOTING, I'm talking about loading the user profile. In the case of Windows - how would you load a profile that's stored on an encrypted (still locked) partition? When you enter the username/password, the system tries to load the profile from D but can't becuase it's locked. But you can't unlock it until after you log in.
See the problem?
LUKS uses the users password to unlock the partition.
That would be awesome, and totally solve this problem - any know if Bitlocker can do this? I think @dafyre tried but it didn't work.
Ah I lied. Ubuntu uses encryptfs which does the auto unencrypt. LUKS will ask for the password for the home directory.
Edit: eCryptFS. Stupid phone keyboard.
-
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
I do trust Windows, let's just assume that they aren't doing anything wrong. I still don't know how you access an encrypted location during logon so that Windows can load the profile. How are you accomplishing this?
You don't, you decrypt it before logging in. No matter what you do, encryption comes out to be a pain.
HOW? How are you decrypting before logon? This is what Mike wants to know.
Key is stored in the TPM. TPM/Bios/UEFI decrypts the drive in order to boot Windows before login.
This is not what Scott is talking about at all though.
I've not tested this, but any reason it can't work with just one partition like LUKS can?
No clue what LUKS is, but assuming a single partition, how do you do remote updates to an encrypted drive? I'm assuming it can't boot without a user there to type in a password.
We can encrypt home directories and still boot the machine. Why would it not be able to boot? The user data is on a separate drive. I'm lost as to why it wouldn't work.
I'm not talking about BOOTING, I'm talking about loading the user profile. In the case of Windows - how would you load a profile that's stored on an encrypted (still locked) partition? When you enter the username/password, the system tries to load the profile from D but can't becuase it's locked. But you can't unlock it until after you log in.
See the problem?
LUKS uses the users password to unlock the partition.
That would be awesome, and totally solve this problem - any know if Bitlocker can do this? I think @dafyre tried but it didn't work.
Ah I lied. Ubuntu uses encryptfs which does the auto unencrypt. LUKS will ask for the password for the home directory.
How does LUKS work then when you are logging in? I take it in a command line there isn't much if anything to really load up profile wise.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
I do trust Windows, let's just assume that they aren't doing anything wrong. I still don't know how you access an encrypted location during logon so that Windows can load the profile. How are you accomplishing this?
You don't, you decrypt it before logging in. No matter what you do, encryption comes out to be a pain.
HOW? How are you decrypting before logon? This is what Mike wants to know.
Key is stored in the TPM. TPM/Bios/UEFI decrypts the drive in order to boot Windows before login.
This is not what Scott is talking about at all though.
I've not tested this, but any reason it can't work with just one partition like LUKS can?
No clue what LUKS is, but assuming a single partition, how do you do remote updates to an encrypted drive? I'm assuming it can't boot without a user there to type in a password.
We can encrypt home directories and still boot the machine. Why would it not be able to boot? The user data is on a separate drive. I'm lost as to why it wouldn't work.
I'm not talking about BOOTING, I'm talking about loading the user profile. In the case of Windows - how would you load a profile that's stored on an encrypted (still locked) partition? When you enter the username/password, the system tries to load the profile from D but can't becuase it's locked. But you can't unlock it until after you log in.
See the problem?
LUKS uses the users password to unlock the partition.
That would be awesome, and totally solve this problem - any know if Bitlocker can do this? I think @dafyre tried but it didn't work.
Ah I lied. Ubuntu uses encryptfs which does the auto unencrypt. LUKS will ask for the password for the home directory.
How does LUKS work then when you are logging in? I take it in a command line there isn't much if anything to really load up profile wise.
Right. During boot it asks for the volume/drive password.
-
A big plus for LUKS though is you can have more than one key. So an Admin can set a key and a user can also.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
I do trust Windows, let's just assume that they aren't doing anything wrong. I still don't know how you access an encrypted location during logon so that Windows can load the profile. How are you accomplishing this?
You don't, you decrypt it before logging in. No matter what you do, encryption comes out to be a pain.
HOW? How are you decrypting before logon? This is what Mike wants to know.
Key is stored in the TPM. TPM/Bios/UEFI decrypts the drive in order to boot Windows before login.
This is not what Scott is talking about at all though.
I've not tested this, but any reason it can't work with just one partition like LUKS can?
No clue what LUKS is, but assuming a single partition, how do you do remote updates to an encrypted drive? I'm assuming it can't boot without a user there to type in a password.
We can encrypt home directories and still boot the machine. Why would it not be able to boot? The user data is on a separate drive. I'm lost as to why it wouldn't work.
I'm not talking about BOOTING, I'm talking about loading the user profile. In the case of Windows - how would you load a profile that's stored on an encrypted (still locked) partition? When you enter the username/password, the system tries to load the profile from D but can't becuase it's locked. But you can't unlock it until after you log in.
See the problem?
LUKS uses the users password to unlock the partition.
That would be awesome, and totally solve this problem - any know if Bitlocker can do this? I think @dafyre tried but it didn't work.
No bitlocker does not do that. You have to get a third party software to do it.
-
One thing to consider is not doing full disk means that someone can possibly modify or install a modified version of a piece of software or install a key logger on the OS disk. Then the password doesn't matter.
-
@Dashrender said in supporting an office of computers with full drive encryption:
OK, let's assume that is correct, how do you propose protecting that data when the system is booted up and updates are being applied?
By having it be encrypted and even the OS can't access it.
-
@Dashrender said in supporting an office of computers with full drive encryption:
But how did the computer bootup in the first place? The whole reason is the OS isn't encrypted is because we want to be able to do remote updates, which requires the PC to be on and booted. And if the PC can be one and booted without a password supplied, then someone could probably hack the boot partition in an attempt to get the key that I assume must be stored in the OS partition to unlock the data partition upon boot, right?
If the OS has the key, the whole system doesn't work. The key has to be held by the user, not the OS regardless of anything else. Full disk, partial disk (partition encryption)... the key can't be on the drive.
-
@stacksofplates said in supporting an office of computers with full drive encryption:
One thing to consider is not doing full disk means that someone can possibly modify or install a modified version of a piece of software or install a key logger on the OS disk. Then the password doesn't matter.
That's potentially true. Could happen on the UEFI too, though.
-
@stacksofplates said in supporting an office of computers with full drive encryption:
One thing to consider is not doing full disk means that someone can possibly modify or install a modified version of a piece of software or install a key logger on the OS disk. Then the password doesn't matter.
which of course defeats the whole secure thing in the first place.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
One thing to consider is not doing full disk means that someone can possibly modify or install a modified version of a piece of software or install a key logger on the OS disk. Then the password doesn't matter.
which of course defeats the whole secure thing in the first place.
How would someone by expected to install that? 99% of possible installs like that will affect an encrypted drive as much as a non-encrypted one. This is one of those "we mentioned a risk" that isn't a viable real world risk and it sounds reasonable until we apply real world risk to it.
It's not nearly as significant as, say, missing a day of patching.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@stacksofplates said in supporting an office of computers with full drive encryption:
One thing to consider is not doing full disk means that someone can possibly modify or install a modified version of a piece of software or install a key logger on the OS disk. Then the password doesn't matter.
which of course defeats the whole secure thing in the first place.
How would someone by expected to install that? 99% of possible installs like that will affect an encrypted drive as much as a non-encrypted one. This is one of those "we mentioned a risk" that isn't a viable real world risk and it sounds reasonable until we apply real world risk to it.
It's not nearly as significant as, say, missing a day of patching.
You don't think so? Let's assume the boot partition is non encrypted, and Secure Boot is disabled. A janitor could crack it open and install a keylogger.
is that more or less likely than being hacked because you didn't patch? OK probably a lot less likely.
-
@Dashrender said in supporting an office of computers with full drive encryption:
It's not nearly as significant as, say, missing a day of patching.
You don't think so? Let's assume the boot partition is non encrypted, and Secure Boot is disabled. A janitor could crack it open and install a keylogger.
I'm not saying that he can't, but if your own staff is your concern, encryption is really not going to do anything. He's got a hundred other ways to do more damage. For example, he's install a physical keylogger that bypasses your full disk encryption because that's even easier than that. He's not bother with this method, because it's not the path of least resistance to this end game.
-
In the janitor scenario... remember that if the laptop (assuming that it is a laptop) is properly secured he'll not have any attack against an unencrypted drive except to remove it physically from the machine, hook it up to another machine and infect it that way. If he could bypass the password and logon stage, you'd be compromised already so we can ignore that.
In the case where he has the physical access to attack the unencrypted system with a key logger to go after the encrypted portion, he's got access to bypass everything and make the attack moot.
-
I saw this marked as solved but can't seem to find the post that mentions the solution/what the OP ended up doing.
-
@wrx7m said in supporting an office of computers with full drive encryption:
I saw this marked as solved but can't seem to find the post that mentions the solution/what the OP ended up doing.
He was only fact finding. It's not his customer. he was trying to determine the cost to support the customer.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
In the janitor scenario... remember that if the laptop (assuming that it is a laptop) is properly secured he'll not have any attack against an unencrypted drive except to remove it physically from the machine, hook it up to another machine and infect it that way. If he could bypass the password and logon stage, you'd be compromised already so we can ignore that.
In the case where he has the physical access to attack the unencrypted system with a key logger to go after the encrypted portion, he's got access to bypass everything and make the attack moot.
That was kind of my point. If the whole drive is encrypted there isn't anything they can do on the disk itself. If the OS isn't encrypted you can essentially do anything.
We have labels that cover the side panels that you can't pull off and reattach. So they can't put anything in the machine without it being obvious. But if the OS isn't encrypted, they could boot to a recovery and chroot into the OS and install whatever they want (assuming BIOS allows media booting, etc).
With the full disk encryption, they can't do anything without the key.
-
@stacksofplates said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
In the janitor scenario... remember that if the laptop (assuming that it is a laptop) is properly secured he'll not have any attack against an unencrypted drive except to remove it physically from the machine, hook it up to another machine and infect it that way. If he could bypass the password and logon stage, you'd be compromised already so we can ignore that.
In the case where he has the physical access to attack the unencrypted system with a key logger to go after the encrypted portion, he's got access to bypass everything and make the attack moot.
That was kind of my point. If the whole drive is encrypted there isn't anything they can do on the disk itself. If the OS isn't encrypted you can essentially do anything.
We have labels that cover the side panels that you can't pull off and reattach. So they can't put anything in the machine without it being obvious. But if the OS isn't encrypted, they could boot to a recovery and chroot into the OS and install whatever they want (assuming BIOS allows media booting, etc).
With the full disk encryption, they can't do anything without the key.
But that was my point. If your OS was secured, you'd not be able to boot to any recovery. The only way it would be to break into the physical box and both are compromised at that point. It's not OS encryption that protects you in that case.
