[RFC v3 5/6] kas-container: block usage of sudo in isar-rootless mode

[Felix Moessbauer]

After switching to the builder user, we prohibit using sudo. This helps
downstream layers to find locations where sudo is incorrectly used, as
well as it prevents accidential breakout on system docker.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
container-entrypoint | 11 +++++++++++
kas-container | 1 +
2 files changed, 12 insertions(+)

diff --git a/container-entrypoint b/container-entrypoint
index da0c36d3a..9d23b6248 100755
--- a/container-entrypoint
+++ b/container-entrypoint
@@ -168,6 +168,17 @@ if [ "$PWD" = / ]; then
cd /builder || exit 1
fi

+if [ "$KAS_BLOCK_SUDO" = "1" ]; then
+ mkdir -p /usr/local/libexec
+ cat <<'EOF' > /usr/local/libexec/kas-no-sudo
+#!/bin/sh
+printf "KAS_BLOCK_SUDO=1: sudo is prohibited\n" >&2
+exit 1
+EOF
+ chmod +x /usr/local/libexec/kas-no-sudo
+ ln -sf /usr/local/libexec/kas-no-sudo /usr/bin/sudo
+fi
+
if [ -n "$1" ]; then
case "$1" in
build|checkout|clean*|diff|dump|for-all-repos|lock|menu|purge|shell|-*)
diff --git a/kas-container b/kas-container
index 38f4992cc..25ef1fd15 100755
--- a/kas-container
+++ b/kas-container
@@ -177,6 +177,7 @@ enable_isar_rootless_mode()
fi
ISAR_ROOTLESS_MODE=1
KAS_CONTAINER_IMAGE_NAME_DEFAULT="kas-isar"
+ KAS_RUNTIME_ARGS="${KAS_RUNTIME_ARGS} -e KAS_BLOCK_SUDO=1"

# Use --privileged to pass the ambient capabilities into the container.
# When calling from the user session (podman or docker-rootless), this
--
2.51.0

[Jan Kiszka]

Rather than patching on invocation, how about adding a wrapper
permanently that checks KAS_BLOCK_SUDO and either calls sudo or rejects
this?

Jan

> +fi
> +
> if [ -n "$1" ]; then
> case "$1" in
> build|checkout|clean*|diff|dump|for-all-repos|lock|menu|purge|shell|-*)
> diff --git a/kas-container b/kas-container
> index 38f4992cc..25ef1fd15 100755
> --- a/kas-container
> +++ b/kas-container
> @@ -177,6 +177,7 @@ enable_isar_rootless_mode()
> fi
> ISAR_ROOTLESS_MODE=1
> KAS_CONTAINER_IMAGE_NAME_DEFAULT="kas-isar"
> + KAS_RUNTIME_ARGS="${KAS_RUNTIME_ARGS} -e KAS_BLOCK_SUDO=1"
>
> # Use --privileged to pass the ambient capabilities into the container.
> # When calling from the user session (podman or docker-rootless), this


--

Siemens AG, Foundational Technologies
Linux Expert Center

[MOESSBAUER, Felix]

This is technically challenging. We would have to replace the
/usr/bin/sudo binary with the wrapper, as the PATH only contains
/usr/bin in some execution contexts. Moving setuid binaries around is a
risk at its own.

Further, we really want to enforce this hardening by making it
impossible to call sudo.

Felix

[Jan Kiszka]

Ok, so this should be seen as security feature? There is then no other
way to go from builder user to root inside the unprivileged container
anymore?

Jan

[MOESSBAUER, Felix]

Actually I would prefer to not even have sudo installed, but as we use
the same container for privileged and non-privileged execution, this is
the workaround (and it also helps to issue a meaningful error message
on accidental sudo invocation).

AFAIK, there is no way to switch users, given that switching via su is
not possible as we don't set a password for root.

So yes, it's a security feature.

Felix

[Jan Kiszka]

Hmm, but what are the extra privileges one can gain from getting root in
a rootless container?

[MOESSBAUER, Felix]

That depends on how the container is started. If it is a vanilla
docker, root inside the container is basically the same as root on the
host. On docker rootless or podman you're right, root in the container
cannot gain relevant extra privileges.

Felix

[Jan Kiszka]

So this is only targeting regular docker startups without sudo needs.

Conceptually, it should affect yocto builds as well. We are installing
sudo and granting password-less access already as base image level. Only
blocking isar-unprivileged would be inconsistent.

[MOESSBAUER, Felix]

In this case it is a security boundary. In the other cases, it just
emits a better error message - and a way to find remaining sudo calls.

>
> Conceptually, it should affect yocto builds as well. We are installing
> sudo and granting password-less access already as base image level. Only
> blocking isar-unprivileged would be inconsistent.

I'm wondering if this is a legacy thing, as Yocto can be built for
quite some time fully rootless. It even prohibits sudo via it's task
executor by switching to a new user namespace (a side effect of that)
[1].

[1]
https://github.com/openembedded/bitbake/blob/e9a06f79d9ec767c9d95470be78b006d6fd0d59c/lib/bb/utils.py#L2020

Probably it would be better to drop sudo in the yocto container as well
(as part of the ongoing host tooling cleanup).

Felix

[Jan Kiszka]

That's my point: if we do this, let's do it consistently.

The how is just not fully clear yet. I could imagine (but I have not
evidence) that some users are exploiting the sudo for installing further
dependencies on the fly. That would continue to be okay'ish for
unprivileged containers.

[MOESSBAUER, Felix]

How about just dropping this patch and applying the rest of the series
so that we can move forward on the isar side?

That gives us time to clarify how to warn / discourage the sudo usage.

PS: Unfortunately we can't use the bitbake blocking of sudo in
rootless, as [1] also blocks our further splitting of namespaces.

Felix