0

There are two disks, one with a read-only filesystem, which holds the installation and configuration files (think root, usr, opt). The second disk is encrypted and holds everything dynamic and user data (think home, srv, var).

There is no swap and /tmp is on a ramdisk.

What are the security risks vs an fully encrypted filesystem?

Christian
  • 453
  • 4
  • 9

1 Answers1

1

Assume an attacker Grace who has physical access to your machine.

She doesn't know your password and wants access to the data stored on the encrypted disk. You will only type in your password if the machine seems not to have been tampered with. Plugging a device which stores everything you type on your keyboard between the keyboard's USB cable and your computer or hiding a microphone which records what you type (yes, that's actually possible) is risky because those modifications can be found.

So Grace decides to go a different path. She assumes that you won't swap out your read-only disk (bwt.: I hope it's a read-only disk because if it's only a read-only FS like you describe in your questions, you have a lot more to worry about) and on day α copies your read-only disk onto a disk of her and also writes down which read-only disk you're using.

She then figures out what program receives the password when type it in and modifies it so that it's stored in a place of the encrypted hard disk which probably isn't accessed during normal usage if the password is correct. She then swaps out the program on the copy of the read-only disk for her modified version and copies the FS to one of the same model of read-only disks you're using and makes it unwritable.

On day β, she takes her read-only disk to your computer and swaps your disk out for hers.

She then just waits until you use the computer and subsequently on day γ copies the contents of your encrypted disk.

Afterwards, she can decrypt everything.

This would not have been possible had you only used a single encrypted disk.

UTF-8
  • 2,300
  • 1
  • 9
  • 24
  • Well, if you have only a single encrypted disk, **somewhere** there has to be unencrypted code to actually decrypt it. This has to be in the bootloader/EFI/... This leaves the exact same attack vector open. – Josef Aug 17 '16 at 07:14
  • Ok, I get your point. But /boot can never be encrypted, so Grace would always be able to swap out my kernel. If my kernel is not what I think it is, every other security feature is pointless, isn't it? – Christian Aug 17 '16 at 07:14
  • You're right. I didn't think about this when posting (though certainly many times before). I'll try to defend my point, though: `/boot` is very small (~ 100 MB). You can easily hash it to figure out whether someone tampered with it after logging in. Hashing would happen with a salt stored in the encrypted part of the disk. Hashing the read-only disk every time you log in would be hard because `/usr` is big. – UTF-8 Aug 17 '16 at 15:09
  • I want to add another point. If you have a read-only disk containing `/usr` you'll probably not update your applications often. Applications should be updated every day. Putting it on a regular disk, however, wouldn't restrict your ability to update applications. – UTF-8 Aug 17 '16 at 15:12
  • even better (and now the used scheme), I can put boot on any removable media and take it with me/lock it in my safe. – Christian Aug 29 '16 at 14:23
  • How would it make a difference for your ability to lock the hard disk in a safe? Furthermore: You'd be bey better off getting a slightly bigger safe and a laptop so no one can install a wiretapping device for example on your keyboard. – UTF-8 Aug 29 '16 at 14:37
  • It's a homeserver, there is no keyboard. Also Linux doesn't need /boot after booting, but it does need /usr. So I can take away my usb drive, but not my hard disk – Christian Aug 29 '16 at 17:22