1cc9e07b7c
Sometimes locations such as /var/lib/flatpak, /var/lib/systemd/coredump
and /var/log/journal sit on security hardened mount points that are
marked as 'nosuid,nodev,noexec' [1]. In such cases, when Toolbx is used
rootless, an attempt to bind mount these locations read-only at runtime
with mount(8) fails because of permission problems:
# mount --rbind -o ro <source> <containerPath>
mount: <containerPath>: filesystem was mounted, but any subsequent
operation failed: Unknown error 5005.
(Note that the above error message from mount(8) was subsequently
improved to show something more meaningful than 'Unknown error' [2].)
The problem is that 'init-container' is running inside the container's
mount and user namespace, and the source paths were mounted inside the
host's namespace with 'nosuid,nodev,noexec'. The above mount(8) call
tries to remove the 'nosuid,nodev,noexec' flags from the mount point and
replace them with only 'ro', which is something that can't be done from
a child namespace.
Note that this doesn't fail when Toolbx is running as root. This is
because the container uses the host's user namespace and is able to
remove the 'nosuid,nodev,noexec' flags from the mount point and replace
them with only 'ro'. Even though it doesn't fail, the flags shouldn't
get replaced like that inside the container, because it removes the
security hardening of those mount points.
There's actually no benefit in bind mounting these paths as read-only.
It was historically done this way 'just to be safe' because a user isn't
expected to write to these locations from inside a container. However,
Toolbx doesn't intend to provide any heightened security beyond what's
already available on the host.
Hence, it's better to get out of the way and leave it to the permissions
on the source location from the host operating system to guard the
castle. This is accomplished by not passing any file system options to
mount(8) [1].
Based on an idea from Si.
[1] https://man7.org/linux/man-pages/man8/mount.8.html
[2] util-linux commit 9420ca34dc8b6f0f
https://github.com/util-linux/util-linux/commit/9420ca34dc8b6f0f
https://github.com/util-linux/util-linux/pull/2376
https://github.com/containers/toolbox/issues/911
|
||
|---|---|---|
| .github | ||
| data | ||
| doc | ||
| images | ||
| playbooks | ||
| profile.d | ||
| src | ||
| test | ||
| .codespellexcludefile | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| .zuul.yaml | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| gen-docs-list | ||
| GOALS.md | ||
| meson.build | ||
| meson_options.txt | ||
| meson_post_install.py | ||
| NEWS | ||
| README.md | ||
| SECURITY.md | ||
| toolbox | ||
Toolbox is a tool for Linux, which allows the use of interactive command line environments for development and troubleshooting the host operating system, without having to install software on the host. It is built on top of Podman and other standard container technologies from OCI.
Toolbox environments have seamless access to the user's home directory, the Wayland and X11 sockets, networking (including Avahi), removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc..
This is particularly useful on OSTree based operating systems like Fedora CoreOS and Silverblue. The intention of these systems is to discourage installation of software on the host, and instead install software as (or in) containers — they mostly don't even have package managers like DNF or YUM. This makes it difficult to set up a development environment or troubleshoot the operating system in the usual way.
Toolbox solves this problem by providing a fully mutable container within
which one can install their favourite development and troubleshooting tools,
editors and SDKs. For example, it's possible to do yum install ansible
without affecting the base operating system.
However, this tool doesn't require using an OSTree based system. It works equally well on Fedora Workstation and Server, and that's a useful way to incrementally adopt containerization.
The toolbox environment is based on an OCI
image. On Fedora this is the fedora-toolbox image. This image is used to
create a toolbox container that offers the interactive command line
environment.
Note that Toolbox makes no promise about security beyond what's already available in the usual command line environment on the host that everybody is familiar with.
Installation & Use
See our guides on installing & getting started with Toolbox and Linux distro support.