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