From Fedora Project Wiki
m (→‎How To Test: -- We don't change the timeout for now)
m (Update re. GRUB2 timeout)
 
Line 184: Line 184:
* GRUB 2 menu
* GRUB 2 menu
** Make sure Developer Mode is not the default entry
** Make sure Developer Mode is not the default entry
** Make sure that any regeneration of the grub.cfg (e.g. from an atomic upgrade/rollback/rebase, or an explicit grub2-mkconfig) brings back a GRUB 2 timeout of 1 second
** Make sure that the GRUB 2 timeout is still 1 second
** Make sure that atomic upgrade/rollback/rebase preserves the Developer Mode boot menu item
** Make sure that atomic upgrade/rollback/rebase preserves the Developer Mode boot menu item
* Statelessness
* Statelessness

Latest revision as of 15:16, 26 April 2016


Atomic Developer Mode

Summary

Add a "Developer Mode" boot menu entry in the Atomic image to allow users to boot without setting up cloud-init.

Owner

  • Name: Jonathan Lebon
  • Email: jlebon@redhat.com
  • Release notes owner:
  • Product: Atomic Image
  • Responsible WG: Cloud SIG

Current status

Detailed Description

The high-level goal of Atomic Developer Mode is to make the Fedora Atomic Host image more accessible by providing a new GRUB 2 menu item labeled e.g. "Fedora 24 (Twenty Four) Developer Mode". This mode is an attempt to provide a painless experience for folks who want to try out Atomic but (1) do not want to bother setting up a cloud-init datasource, or (2) do not know anything about cloud-init, or even (3) do not have much experience with Linux overall. They just want to try out e.g. /usr/bin/atomic, /usr/bin/docker, or play with the Cockpit console.

Since the functionality is completely integrated into the image, there are no requirements on the host system, other than its ability to boot VMs. When booted in Developer Mode, the following happens:

  • cloud-init uses a local built-in datasource
  • a new root password is generated
  • the root user is automatically logged in on tty1
  • the cockpit/ws image is downloaded and started
  • a tmux session is started on tty1 to provide all the relevant information (root password, IP address, Cockpit console address)

More information and discussion can be found on the Cloud SIG mailing list.

How It Works

Atomic Developer Mode uses the same ostree deployment as the top-most entry (i.e. the default boot entry). Whenever a new grub.cfg is generated (e.g. by doing an rpm-ostree upgrade/rollback/rebase), the Developer Mode entry is also updated to point to the new default deployment.

In the kernel command-line, a cloud-init argument is provided so that during the boot process, it does not try to contact e.g. the OpenStack metaserver (and eventually hang), but instead uses local metadata installed by the atomic-devmode package. It is this cloud-init metadata that bootstraps the Developer Mode experience.

A core requirement of the Developer Mode feature is statelessness. This means that even if one has booted into Developer Mode, later boots should show no remnants or artifacts of that effect (no auto-login, no auto-generated root password, etc...).

Security Considerations

It may be seen as a security issue to be able to boot directly into an autologged in root shell. However, this would require access to the GRUB 2 menu. If you are planning to run Atomic Host in an environment in which a malicious user may have access to the boot menu (e.g. in a kiosk setup), then you should lock it regardless of the presence of a Developer Mode installed or not.

Otherwise, the malicious user will be able to edit the kernel command-line for any boot entry and point cloud-init to a datasource which will e.g. set the root password to a predefined string.

As a POC, you should be able to boot the current Fedora Atomic Host image, and at boot time, press 'e' to edit the menuentry and appending the following to the boot option:

 ds=nocloud-net\;s=http://jlebon.fedorapeople.org/bad-cloud-init/

Once booted, you should be auto-logged in as root.

Even if network access is blocked, one simply has to append rw init=/bin/bash to the kernel cmdline, write the meta-data locally, reboot, and then point cloud-init to the local datasource (or just skip all that and disable cloud-init and set a root password).

Thus, the Developer Mode feature does not introduce a new security vulnerability in that space, although it can make it more convenient. It is always possible to delete the Developer Mode menu entry by doing:

 /usr/libexec/atomic-devmode/bootentry remove

Benefit to Fedora

The major benefit is to make Fedora Atomic Host more approachable to folks of all skill levels. This includes simplifying and reworking the Project Atomic Quick Start Guide to omit the whole section on cloud-init setup.

Scope

  • Proposal owners:
    • Create an atomic-devmode package to hold the helper files needed for this feature -- DONE
    • Add the atomic-devmode package to the Fedora repos -- DONE
    • Submit the necessary changes to repos related with tree and image creation:
      • 1. Submit a patch to fedora-atomic to have the atomic-devmode package part of the default tree compose -- DONE
      • 2. Submit a patch to spin-kickstarts to have the boot menu item added in the kickstart %post -- DONE
    • Work with projectatomic.io maintainers to properly present Atomic Developer Mode (including updating the Quick Start Guide)
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The big win for Atomic Developer Mode is the ability to easily boot without setting up cloud-init. If a user is able to upgrade their Atomic Host, it means that cloud-init has already been set up. That said, after upgrading to (and rebooting into) a tree which has the atomic-devmode package, if users desire to have the Developer Mode boot menu item, they will have to manually run:

# /usr/libexec/atomic-devmode/bootentry add

How To Test

Atomic Developer Mode can be tested by anyone with access to a virtualization platform, either locally or in the cloud.

Test aspects:

  • GRUB 2 menu
    • Make sure Developer Mode is not the default entry
    • Make sure that the GRUB 2 timeout is still 1 second
    • Make sure that atomic upgrade/rollback/rebase preserves the Developer Mode boot menu item
  • Statelessness
    • Make sure that even if Developer Mode was booted once, it leaves no undesirable artifacts when booting using a regular cloud-init source (e.g. no auto-login, no auto-root pw generation, etc...)
  • Error handling
  • Make sure that Developer Mode errors out gracefully when the machine has no Internet access
  • Make sure that Developer Mode errors out gracefully when the Cockpit image fails to be downloaded or run
  • User experience
    • [Subjective] Make sure that the system is approachable enough by folks who may not have much experience with Fedora, cloud, or Linux, but are tech-savvy enough to follow instructions and use the command-line.

User Experience

Users of the Fedora Atomic Host image will see a new boot menu item.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)
    • Revert the patch to spin-kickstarts so that the new boot menu item does not appear.
    • Revert the patch to fedora-atomic so that the atomic-devmode package is no longer part of the default tree compose.
  • Contingency deadline: Beta
  • Blocks release? No
  • Blocks product? No

Documentation

Documentation includes this very page and the upstream source for atomic-devmode.

Release Notes

TBD