On Thursday, December 12, 2019 6:04:55 AM MST Marius Schwarz wrote: > because I already tried it ;) it's a tty problem with high secure ttys, > hvcsomething. Thats the only one, the system accepts input from at > start, but with QEMU that tty isn't present. Adding the normal ttys to > the trusted list of ttys did not fix the issue. I had a br running years > ago, but it got never solved afaik. > > Maybe i should try again, as the last test was approx. 5 years ago. I'd have to take a look at a test system, I'm running a Xen setup with CentOS 7 DOM0, have no issues with Plymouth on other domains. > If you have an offhost storage, as mass storage at a cloudhoster would > be, the transport from the storage to the host needs to be secured too, > which i don't think it is. So i don't think we need to even consider VMs > to be encryptable, as securing the entire path is very tough and out of > our league. Well, luckily, that's not necessary. VMs have a lot of issues when it comes to security, but using LUKS is sufficient on a drive or partition, as no unecrypted data would go across the SAN. It's just what would be written to disk. Well, if you're using a block device from SAN, that is. I'm not accounting for NFS here, which can be secured using NFSv4. > > Are you suggesting "translating", for lack of a better term, the > > passphrase between all available keyboard layouts? That would decrease > > the effective security of your system considerably.. > > No, i mean, there can be two different passcodes for the same key. Luks > offers 10 slots for them. > On can be plain ascii as it's now, the other one can be the one the > system had been installed with. > > See it as a "Reserve- or Backuppassword", but in no way it should be a > none-interactive password aka controlled by the installer. We don't need > backdoors. Ah, gotcha! That's a neat idea. I like it. That'd be a very nice way to handle it, potentially with an option in the installer to export that to a removable device for safe-keeping. -- John M. Harris, Jr. Splentity _______________________________________________ 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
