Allow controlling autologin through a flag file

[omniproc]

Description

Deploying Flatcar currently results in a unlocked / not-password-protected console by default.

Impact

We considere this a security issue since anyone with permissions to access the console is also able to perform changes to Flatcar without authentication. Currently there doesn't seem to be a way to disable this behaviour at bootstrap time which means that we'd need to run additional scripts after bootstrap - weakening the purpose of the bootstrap process.

Environment and steps to reproduce

1. Deploy Flatcar 2765.2.3 using the OVA or ISO release. Use the ignition bootstrap process with the following config to disable autologin.

{
  "ignition": {
    "version": "2.2.0"
  },
  "storage": {
    "files": [
      {
        "filesystem": "oem",
        "path": "/grub.cfg",
        "contents": {
          "source": "data:text/plain,set%20oem_id%3D%22vmware%22%0D%0A%23set%20linux_append%3D%22flatcar.autologin%22"
        }
      }
    ]
  }
}

Using that ignition we disable the line set linux_append="flatcar.autologin" which seems to be enabled by default and responsible for the "auto login" behaviour.

Expected behavior

Flatcar bootstrap should success and we should end up with a flatcar instance that has autologin disabled - this is "console login" is disabled and/or requires logon authentication (which is not configured and thus not possible).

Actual behavior

Flatcar will hang in a bootloop when the grub.cfg is edited at bootstap time.

[pothos]

The docs to disable autologin are here and as you said it needs an additional reboot. Why the boot breaks is your case is not clear without logs. Please try again to follow the docs and provide the log output.

I don't see the autologin as a real security issue. Who has access to the console of the VM and if they have access, don't they also have access to other destructive VM actions? Even if you lock the user access down to only console access, this is still not safe because the user can trigger a reboot with Ctrl-Alt-Del (or wait for it after a new release), enter the GRUB menu and give arbitrary kernel boot parameters (among them is also flatcar.autologin again).

[omniproc]

Hi.

thanks for the reply. I'll double check and try to provide logs. This is kinda hard probably since, as I said, currently we end up in a boot loop. But if you say you tested this and it works in general on your system I'll try to find out why it didn't in our tests.

Regarding your arguments around security however I have to disagree.

I don't see the autologin as a real security issue. Who has access to the console of the VM and if they have access, don't they also have access to other destructive VM actions?

Depending on the environment / platform the users with access to the console may be different from users responsible for the operation of the Flatcar instance. You imply trust between this two roles but there are quite many scenarios where that doesn't need to be true. Also "destroying" something is not the worst thing you can do. Stealing data by unauthorized access is a way bigger threat and with access to the system an attacker can run - whatever attack - undetected for as long as he wants.

IMHO everyone should do their part to secure a system which means you should not rely on the security of systems that you don't control, e.g. access to the console or make assumptions about them.

From my exp. nearly every single image / appliance from any vendor started years ago with a setup as Flarcar today. All that I'm aware of of them moved away from:

• default passwords (not the case here)
• Autologon (yes sir)
• GRUB menu / editable kernel boot params without authentication (see next part)

So if you're right with your Assumption that this is not needed and can be worked around anyway and your conclusion that thus, it's not required, then I guess anyone in InfoSec must have been wrong about this and all over vendors are doing it wrong? Why do we even have logon prompts for server systems anyways if they're useless?...

Even if you lock the user access down to only console access, this is still not safe because the user can trigger a reboot with Ctrl-Alt-Del (or wait for it after a new release), enter the GRUB menu and give arbitrary kernel boot parameters (among them is also flatcar.autologin again).

Correct. So to close this (quite easily exploitable) attack vector most vendors that distribute images / appliances also disabled the GRUB menu by default.

And sure: we don't have to debate about "software locks" of unencrypted systems. I'm well aware you can access any system that doesn't have full disk encryption this way or another, even with GRUB menu disabled. But that's not what logon promps are for. They add a additional layer of security for a well defined set of attack vectors. This can be simple drive-by attacks or very simple automated attacks. They don't protect your from everything that an attacker could do but they do prevent you from some attacks and thus it's common to close that (easily exploitable) attack vector.

And last but not least: even if you don't consider this as a mechanism that actually adds security you still should consider this a thing. Why? Because of audits. If Flatcar should be used by large scale companies in production and not just startups and kiddos fiddling with K8s I guarantee you auditability / authentication logs are something those people want to see, whether you think it makes sense or not doesn't really matter at that point. And sure: not all big companies take this serious. But quite enough do. Plus: it's an easy fix from your side.

So please: I encourage you to re-think the possition you took on this.

Thanks

[pothos]

I mainly agree with you, but don't want to sell disabling autologin as security feature when the GRUB menu is still there. It makes sense to disable both together and we should document this. Default behavior is another question. My preference would be to have the VMware guestinfo variables as a way to control autologin. This makes it easily accessible at any time and allows to turn the default off.

[gunzy83]

I ran into this running the QEMU image on Proxmox. I did think it was a bit weird that the core user was automatically logged in, and I could interact with it via the web interface. After reading this issue I agree with @pothos that unless you closed the exploit in grub as well it is pointless changing the default.

I addressed this by creating a second user in my ignition config and removing passwordless sudo and docker access from the core user.

[pothos]

I addressed this by creating a second user in my ignition config and removing passwordless sudo and docker access from the core user.

Or you can remove flatcar.autologin from /usr/share/oem/grub.cfg. Since you download the image anyway, you can customize the OEM partition's grub.cfg before booting by mounting it as loop device with either qemu-img convert or, better, through:

guestmount -m /dev/sda6 -a flatcar_production_qemu_image.img /var/tmp/mountpoint
sed -i "s/flatcar.autologin//g" /var/tmp/mountpoint/grub.cfg
guestunmount /var/tmp/mountpoint/

[gunzy83]

I addressed this by creating a second user in my ignition config and removing passwordless sudo and docker access from the core user.

Or you can remove flatcar.autologin from /usr/share/oem/grub.cfg. Since you download the image anyway, you can customize the OEM partition's grub.cfg before booting by mounting it as loop device with either qemu-img convert or, better, through:

guestmount -m /dev/sda6 -a flatcar_production_qemu_image.img /var/tmp/mountpoint
sed -i "s/flatcar.autologin//g" /var/tmp/mountpoint/grub.cfg
guestunmount /var/tmp/mountpoint/

Thanks for the tip. I might include that the next time I create a new Proxmox VM template or when I automate updating the template.

[jepio]

@pothos suggests extending https://github.com/flatcar-linux/init/blob/flatcar-master/systemd/system-generators/flatcar-autologin-generator to react to a flag file (flatcar-no-autologin) or (re)parsing grub.cfg so that this can be influenced via ignition and applied at instance creation.

[pothos]

The new Alpha has Ignition v3 which includes the "kargs" directive to set kernel parameters and reboot from the initramfs to make them match the expected values

TODO: call this out in the docs that talk about autologin

[gunzy83]

The new Alpha has Ignition v3 which includes the "kargs" directive to set kernel parameters and reboot from the initramfs to make them match the expected values

TODO: call this out in the docs that talk about autologin

This has been very useful but comes with a caveat: it requires transpiling from Butane config (Coreos) which has deprecated systemd-networkd support (Coreos uses NetworkManager). Luckily, ignition will attempt to create files that do not require network access before starting the network, so something like this will work:

storage:
  files:
    - path: /etc/systemd/network/10-mgmt.network
      mode: 0644
      overwrite: true
      contents:
        inline: |
          [Match]
          MACAddress=xx:xx:xx:xx:xx:xx
          Type=!vlan bond bridge

          [Network]
          LinkLocalAddressing=no
          Address=192.168.1.12/24
          Gateway=192.168.1.1
          DNS=192.168.1.1
          Domains=mgmt.local

[pothos]

Many ways are now documented in https://www.flatcar.org/docs/latest/setup/customization/other-settings/#adding-custom-kernel-boot-options

In particular, this one is maybe worth mentioning again here:

systemd:
  units:
    - name: getty@.service
      dropins:
        - name: 10-autologin.conf
          contents: |
            [Service]
            ExecStart=
            ExecStart=-/sbin/agetty --noclear %I $TERM

It would still be nice to have this directly configurable through a flag file:

@pothos suggests extending https://github.com/flatcar-linux/init/blob/flatcar-master/systemd/system-generators/flatcar-autologin-generator to react to a flag file (flatcar-no-autologin) or (re)parsing grub.cfg so that this can be influenced via ignition and applied at instance creation.