Security best practice to remove autologin

[andy-v-h]

Removing autologin

having autologin on the kernel args goes against security best practices. It leaves the terminal logged in on a privileged user. Removing this does mean that Equinix Metal/Packet SOS cannot be used to access the host without additional host configuration but we would recommend this for our users in general.

How to use

Installing from a release with this grub.cfg

Testing done

I've toggled this kernel arg several times on packet/equinix metal hardware. This has the expected prompt or not.

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)

[pothos]

Recommend to disable it or disable it by default? With Ignition v3 it's easier to set the kernel parameters now and we could document how to do this. I'm a bit worried to have it off by default and people are left with no way of accessing the instance in an emergency event. I would like to understand the attack vector better, e.g., if the assumption is physical access then there are ways to force a reboot and use the serial console by modifying the GRUB kernel parameters.

[andy-v-h]

Recommend to disable it or disable it by default? With Ignition v3 it's easier to set the kernel parameters now and we could document how to do this. I'm a bit worried to have it off by default and people are left with no way of accessing the instance in an emergency event. I would like to understand the attack vector better, e.g., if the assumption is physical access then there are ways to force a reboot and use the serial console by modifying the GRUB kernel parameters.

Ah, great clarifying question. Disable by default is my goal here. Having a method to enable it for OOB access is still key.

[pothos]

So, the way people could get OOB access would either be by specifying a password for the core user (or another user) and check that SSH password auth is disabled, or by specifying the autologin kernel parameter. The recommendation would be that this happens on provisioning time or shortly after because one needs a few additional steps to do it when the OOB console suddenly is the last resort.
These steps are: rebooting the instance, hitting 'e' in the GRUB menu and adding the autologin kernel parameter.
Since these steps are possible in both cases of having physical access or getting access to the web UI/API, I don't really see it as a security achievement to disable autologin by default. Instead of having instant access, the only difference is that a short reboot occurs but that's anyway quite a normal event with Flatcar updates.
Therefore, I'm not yet convinced that the upsides outweight the downsides. I get that we need to improve the docs, though, for users that want to do it. With the Ignition v3 kargs setting an early reboot occurs at the moment but we can optimize this away by adding a special case that sets up a config file for the autologin mechanism.

[pothos]

Suggested change

* Remove `flatcar.autologin` as a default kernel argument for best practices on packet-oem overlay.

- Equinix Metal: Remove `flatcar.autologin` as a default kernel argument for making it harder to get system access through the serial console. Users that want to use the OOB console have to either set up a user password (and make sure that SSH password login is disabled) or set the kernel argument when provisioning through the Ignition v3 kargs setting (requires Flatcar major version >=3185) ([coreos-overlay#1914](https://github.com/flatcar-linux/coreos-overlay/pull/1914))

[pothos]

Also, I think the changelog/changes/ folder fits this better as no security issue was addressed but an OS change is done that requires users to adapt to the change

[pothos]

To further understand how malicious access could happen, my understanding is that the SSH key for the OOB console access is the same as the one specified for the instance through the SSH keys setting, right? Or are the SSH keys for OOB console access more broad and any personal/project SSH keys get accepted? In the first case the compromise of an SSH key would mean that the attacker has direct SSH access and doesn't need the OOB console. In the other case the compromise of an non-instance SSH key would mean that the attacker needs to find out the server UUID for getting OOB access. The 128 bit server UUID is not public and would need access to the web UI/API and at that point one could already do easier things like adding an SSH key to the instance attributes to gain access and the OOB access is also easily gained by the mentioned reboot into GRUB trick.

[JAORMX]

I agree with this change (as noted by me clicking approve in this PR). While @andy-v-h 's default change may not be a silver bullet for security, it does set up yet another fence that folks need to jump. This is being done with the best intentions for our customers' security and privacy, and it's a setting that we often need to set in our environments (as @andy-v-h noted earlier).

[pothos]

I'll prepare a docs PR to point out the kargs Ignition section to control this.

Merging this is ok, I only want to point out that the UX is worse and little is gained because the fence to jump is not high, it's like more like adding base64 encoding as a security measure – one can't directly read the value unless an additional step is done. I would be more convinced to sell this change as security feature if we had a thread model at hand with a clear case where with high probability this here prevents something from happening.

[pothos]

Docs PR done in flatcar-archive/flatcar-docs#248

[pothos]

Another question, with the merge here we would align Flatcar with other distros like Ubuntu, or would there still be a difference?

[jepio]

I understand the desire to remove autologin, and I in no way mean to block/sabotage this effort. There are some thoughts that I had that I wanted to discuss:

• autologin is so far enabled for Azure/EquinixMetal/VMWare/Qemu. We could move EM to the set of platforms with no autologin, but maybe it's time to move all platforms other than qemu over. This assumes that the qemu platform is more for development purposes.
• I had this idea of disabling autologin if a password for the core user is configured. Is this something that would solve the EM issue? Would the EM installer be able to configure a password for the core user through ignition, or too tricky. I assume making autologin opt-in is the driver for this PR, and keeping it opt-out does not meet your security requirements?

[pothos]

We have many ways documented now to disable autologin:
https://www.flatcar.org/docs/latest/installing/cloud/equinix-metal/#disablingenabling-autologin
The getty@.service drop-in doesn't require a reboot.