Self-assessment

Self-assessment outline

Table of contents

• Metadata
  • Security links
• Overview
  • Actors
  • Actions
  • Background
  • Goals
  • Non-goals
• Self-assessment use
• Security functions and features
• Project compliance
• Secure development practices
• Security issue resolution
• Appendix

Metadata

Security links

Overview

Lima launches Linux virtual machines with automatic file sharing and port forwarding (similar to WSL2).

The original goal of Lima was to promote containerd including nerdctl (contaiNERD ctl) to Mac users, but Lima can be used for non-container applications as well.

Background

A typical usage of Lima is like:

# Install
brew install lima

# Start the VM with the default template
limactl start

# Launch nerdctl (contaiNERD CTL) via Lima
lima nerdctl run --rm hello-world

Lima uses YAML files to define VM templates. See https://github.com/lima-vm/lima/tree/master/examples for the examples of the templates.

A malicious template may break host OS via host filesystem mounts. It is users’s responsibility to avoid using malicious templates.

Actors

• limactl CLI: the CLI provides CRUD operations for VM instances. The CLI does not need the root privilege on the host OS. A template file can be specified on creating an instance as follows:

# Built-in template
limactl create template://docker

# Local path
limactl create /usr/local/share/lima/templates/fedora.yaml

# HTTPS URL (use with a caution)
limactl create https://raw.githubusercontent.com/lima-vm/lima/master/examples/alpine.yaml

• lima CLI: an alias of limactl shell, for logging into the guest OS.

• VM drivers: the following virtual machine drivers are supported (no root privilege is needed):

  • QEMU
  • Apple Virtualization.framework (for macOS hosts)
  • WSL2 (for Windows hosts)

• SSH: Lima generates an SSH keypair and configure the guest OS so that the lima CLI (alias of limactl shell) can login to the guest OS. The SSH port is bound to the localhost of the host OS.

• Port forwarder: localhost ports of the guest OS are forwarded to the localhost of the host OS. These forwarded ports are not exposed to non-localhost by default, but this behavior is customizable.

• (Optional) SFTP: When the filesystem mount type is configured to reverse-sshfs in a VM template, Lima launches an SFTP server process on the host and associate its stream to the SSH process so that the guest OS can mount the host filesystem. The SFTP server process is launched as a non-root user.

• (Optional) socket_vmnet daemon: When the network type is set to lima:shared in a VM template, Lima launches a socket_vmnet daemon with sudo so as to enable enhanced networking mode, e.g., publish the VM’s IP address to the physical network.

Actions

• limactl create: the CLI receives a template file via the argument, and populates the disk image for the instance.

• limactl start: the CLI launches the instance using the specified VM driver, and sets up port forwarding and filesystem mounts. This action does not need the root privilege on the host. When the network mode is set to lima:shared, the CLI launches the socket_vmnet daemon with sudo. The sudoers file for this operation can be generated with the limactl sudoers command.

• limactl sudoers: the CLI generates /etc/sudoers.d/lima file to allow running socket_vmnet. Not needed for the default configuration.

• lima, limactl shell: the CLI launches ssh to login to the VM instance.

• limactl stop: the CLI stops the specified VM instance.

• limactl delete: the CLI deletes the specified VM instance.

Goals

• No root privilege is needed for installing and running VM

• When the root privilege is needed (i.e., socket_vmnet), the privileged operation is performed in a separate process that is confined with the sudoers file

• No port is published to non-localhost by default

Non-goals

• Tolerance to malicious template files is out of our goals. An instance created from a malicious template may read and write host files, depending on the host mounts specified in the template.

Self-assessment use

This self-assessment is created by the Lima team to perform an internal analysis of the project’s security. It is not intended to provide a security audit of Lima, or function as an independent assessment or attestation of Lima’s security health.

This document serves to provide Lima users with an initial understanding of Lima’s security, where to find existing security documentation, Lima plans for security, and general overview of Lima security practices, both for development of Lima as well as security of Lima.

This document provides the CNCF TAG-Security with an initial understanding of Lima to assist in a joint-assessment, necessary for projects under incubation. Taken together, this document and the joint-assessment serve as a cornerstone for if and when Lima seeks graduation and is preparing for a security audit.

Security functions and features

• The security of Lima critically depends on VM drivers (e.g., QEMU, Virtualization.framework), SSH, SFTP, etc. Users have to make sure to install the well-maintained version of these dependencies. On macOS hosts, this can be typically accomplished by clicking the “Software Update” button of the System Preference, and by running brew upgrade.

Project compliance

N/A

Secure development practices

• Development Pipeline:

  • Every commit must be signed off with DCO, and every non-trivial commit must be approved by at least one other Maintainer (Committer or Reviewer). See https://lima-vm.io/docs/community/contributing/ for the further information.
  • Dependabot is enabled to bump up Go dependencies automatically: https://github.com/lima-vm/lima/blob/master/.github/dependabot.yml
  • Vulnerabilities are occasionally scanned with govulncheck

• Communication Channels: GitHub and Slack. See https://lima-vm.io/docs/community/.

• Ecosystem: Lima has been widely adopted in several third-party projects, such as:

  • Rancher Desktop: Kubernetes and container management to the desktop
  • Colima: Docker (and Kubernetes) on macOS with minimal setup
  • Finch: Finch is a command line client for local container development
  • Podman Desktop: Podman Desktop GUI has a plug-in for Lima virtual machines

Security issue resolution

• Responsible Disclosures Process: Vulnerabilities are expected to be reported via https://github.com/lima-vm/lima/security/advisories/new. Those who do not have a GitHub account may also use email to reach out to the Committers directly.

• Incident Response: Committers triage and confirm potential vulnerability reports, and ship a fix as soon as possible. Committers may coordinate with well-known downstreams (e.g., Rancher Desktop, Colima, and Finch) for a disclosure of a serial vulnerability.

Appendix

• Known Issues Over Time: See https://github.com/lima-vm/lima/security/advisories.

  • GHSA-f7qw-jj9c-rpq9 (May 30, 2023): A virtual machine instance with a malicious disk image could read a single file on the host filesystem, even when no filesystem is mounted from the host. Fixed in Lima v0.16.0, by prohibiting using a backing file path in the VM base image.

• CII Best Practices: See https://www.bestpractices.dev/en/projects/6505. Passing.

• Case Studies: See Ranche Desktop (SUSE), Colima, Finch (AWS) below.

• Related Projects / Vendors:

  • Rancher Desktop: Kubernetes and container management to the desktop
  • Colima: Docker (and Kubernetes) on macOS with minimal setup
  • Finch: Finch is a command line client for local container development
  • Podman Desktop: Podman Desktop GUI has a plug-in for Lima virtual machines
  • lima-xbar-plugin: xbar plugin to start/stop VMs from the menu bar and see their running status.
  • lima-gui: Qt GUI for Lima