On 12/09/2018 11:15 AM, Bastian Blank wrote: > On Sun, Dec 09, 2018 at 05:48:20PM +0100, Thomas Goirand wrote: >> If the question is "should we have a generic password", IMO the answer >> is obviously no. The goal of the Debian image is really not the same as >> the Cirros one, and having a well-known password is a security problem. > > No, we don't want a password. But we can have a null-password set, > which can be used from secure terminals, aka tty0 and ttyS0. This seems reasonable for the "VM is in failure state" use case, that is, when there's no network/control plane, we can't expect the VM to act on a new device presented to it (e.g., automount some form of recovery disk) and we can't rely on a custom-built kernel driver to talk to the hypervisor/host to be present/in working state. I've seen some images that create a random root password on first boot and output that to the boot log. Similarly, some vendors create a random password say through their Web interfaces. The issue is that the secret is seldom captured by the user or stored safely. We can foresee some users would not have an issue with the well known password itself but with their inability to rotate it. And for people that are looking beyond the "VM in failure state" use case the blank password in secure terminal won't be acceptable either and might end up looking at x509, otp, etc., for logins. However, I don't think any OS image can be optimized for that right now. In terms of convenience in the "VM in failure state" case, the blank password beats having to intercept the bootloader, and it's reasonable to expect that both the OS as well as the cloud providers would generate log traces and/or use RBAC as an additional layer for console access.
Attachment:
signature.asc
Description: OpenPGP digital signature