On Mon, Dec 9, 2019 at 1:11 PM Przemek Klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 12/6/19 7:19 PM, Kevin Kofler wrote: > > Lennart Poettering wrote: > >> If you know where stuff is located you can change individual blocks in > >> files. You are not going to know what you are changing them to, but > >> you can change it and traditional files will not detect that you did that. > > Then you get unpredictable garbage as the result, which is useless if your > > goal (as the attacker) is to plant a trojan horse that steals encrypted data > > while it is decrypted. (And of course, you cannot directly decrypt the data > > either.) The only way to exfiltrate the data is to attack the system while > > it is running (online). > It's like fuzzing: injecting garbage results in unintended code paths > being taken, which is a stepping stone to gaining execution control. Of > course this happens when the system is started up, so it is a multi-step > process, but if you include that in your threat model you have to worry > about it. Exactly. Trojans, evil maids, ransomware, floor or fuzz attacks, they're all totally reasonable things to be concerned about. But the thing to keep in mind is what is Fedora recommending to most users, by making it a default? Today we aren't doing any encryption by default. So the idea that encrypting ~/ alone as a possible next step somehow translates into meaning we don't care about other possible attack vectors, or that such setups are somehow less secure, is not convincing. It really is about prioritizing and balancing out security with usability. I'm not sure how people are worried about trojans being injected into an unencrypted root, while also not at all concerned about bootloader malware, or malware injected into the initramfs or the hibernation image - which upon resume replaces everything in RAM in favor of what's in the image. The reality of non-Latin character and accessibility support being a nogo in the initramfs and plymouth almost certainly means no resources will go toward making that early boot environment more complex. If anything the developers in this area want that environment simpler, and reproducible. The alternative, to put a fine point on it, would mean creating some small subset of the entire GNOME stack to stuff into the initramfs in order to provide input, keymapping, and UI to have the minimum a11y function and i18n expectations. That's a tough sell. And then what of code reuse for other DE's? Right. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
