Be aware of security hardened mount points #1340
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Build succeeded. ✔️ unit-test SUCCESS in 9m 43s |
debarshiray
changed the title
debarshiray
force-pushed
the
wip/rishi/issue-911
branch
from
a71e0f5
to
65afe2f
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 9m 42s |
Otherwise https://www.shellcheck.net/ would complain: Line 218: source <(echo "$output") ^---------------^ SC1090 (warning): ShellCheck can't follow non-constant source. Use a directive to specify location. See: https://www.shellcheck.net/wiki/SC1090 containers#1347
Otherwise https://www.shellcheck.net/ would complain Line 110: for ((i = ${num_of_retries}; i > 0; i--)); do ^---------------^ SC2004 (style): $/${} is unnecessary on arithmetic variables. See: https://www.shellcheck.net/wiki/SC2004 containers#1347
debarshiray
force-pushed
the
wip/rishi/issue-911
branch
from
65afe2f
to
63b13b0
Compare
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
util-linux/util-linux@9420ca34dc8b6f0f
util-linux/util-linux#2376
containers#911
debarshiray
changed the title
debarshiray
force-pushed
the
wip/rishi/issue-911
branch
from
63b13b0
to
1cc9e07
Compare
|
Build failed. ❌ unit-test RETRY_LIMIT in 32s |
|
The tests run on Fedora Rawhide nodes are failing because of the same reasons as in #1344 and #1331 , and the root cause appears to be rsync: https://bugzilla.redhat.com/show_bug.cgi?id=2229654 So, I am going to temporarily ignore these test failures on Fedora Rawhide. |
debarshiray
pushed a commit
to alatiera/toolbox
that referenced
this pull request
Aug 22, 2023
On new builds of GNOME OS [1], the host's / is mounted with 'nodev,...' and those flags are also inherited by /etc because it's not a separate mount point. This leads to the same problem with /etc/machine-id that was seen before with /var/lib/flatpak, /var/lib/systemd/coredump and /var/log/journal [2]. Therefore, use the same approach [2] to handle /etc/machine-id. [1] https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/718 [2] Commit 1cc9e07 containers@1cc9e07b7c36fe9f containers#1340 containers#911 Signed-off-by: Jordan Petridis <jordan@centricular.com>
debarshiray
pushed a commit
to alatiera/toolbox
that referenced
this pull request
Aug 22, 2023
On new builds of GNOME OS [1], the host's / is mounted with 'nodev,...' and those flags are also inherited by /etc because it's not a separate mount point. This leads to the same problem with /etc/machine-id that was seen before with /var/lib/flatpak, /var/lib/systemd/coredump and /var/log/journal [2]. Therefore, use the same approach [2] to handle /etc/machine-id. [1] https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/718 [2] Commit 1cc9e07 containers@1cc9e07b7c36fe9f containers#1340 containers#911 containers#1354 Signed-off-by: Jordan Petridis <jordan@centricular.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sometimes locations such as
/var/lib/flatpak,/var/lib/systemd/coredumpand/var/log/journalsit on security hardened mount points that are marked asnosuid,nodev,noexec[1]. In such cases, when Toolbx is used rootless, an attempt to bind mount these locations read-only at runtime withmount(8)fails because of permission problems:(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-containeris running inside the container's mount and user namespace and the source paths were mounted inside the host's namespace withnosuid,nodev,noexec. The abovemount(8)call tries to remove thenosuid,nodev,noexecflags from the mount point and replace them with onlyro, 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,noexecflags from the mount point and replace them with onlyro. 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].Note that this isn't a problem when Toolbx is running as root, because the container uses the host's user namespace.
Based on an idea from Si.
[1] https://man7.org/linux/man-pages/man8/mount.8.html
[2] util-linux commit 9420ca34dc8b6f0f
util-linux/util-linux@9420ca34dc8b6f0f
util-linux/util-linux#2376
#911