Can't install packages in scout container on SELinux (Fedora) system

[Spirrwell]

Trying to install any package from inside the scout runtime simply doesn't work anymore.

debconf: delaying package configuration, since apt-utils is not installed
dpkg: error processing archive /var/cache/apt/archives/nasm_2.09.10-1_i386.deb (--unpack):
 cannot open security status notification channel
No apport report written because MaxReports is reached already
                                                              Errors were encountered while processing:
 /var/cache/apt/archives/nasm_2.09.10-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Installing packages from inside soldier seems to work just fine. This happens whether I use i386 scout or the plain scout container

Reproduce with apt-get install nasm or any package.

[slembcke]

Huh, I just ran into this same problem. I works fine on my machines running Ubuntu + docker, but I get that same error running it under Fedora using docker or podman. My knowledge of containers is that they are basically VM's, but not quite... Still, I thought the point of running builds in them was to isolate them from the host system. I'm baffled what could be going on here.

Also might be worth noting that if I download the package and install it directly with dpkg, I get the same error. Ex:

(steamrt scout 0.20220601.1)root@4f8fca7a650c:/tmp# apt-get download zip
Get:1 Downloading zip 3.0-4 [262 kB]
Fetched 262 kB in 1s (262 kB/s)
(steamrt scout 0.20220601.1)root@4f8fca7a650c:/tmp# dpkg -i zip_3.0-4_amd64.deb 
dpkg: error processing archive zip_3.0-4_amd64.deb (--install):
 cannot open security status notification channel
Errors were encountered while processing:
 zip_3.0-4_amd64.deb

[Spirrwell]

Aha, I didn't even think to mention I was on Fedora because I thought "oh it's a container." But yes! I don't have this problem on my Manjaro (Arch) installation, but it does happen on Fedora.

[slembcke]

Asking around in some developer chats, I got a "it's probably some SELinux thing that Fedora does" response two different times. I guess that sounds like a plausible lead? It is a security error, and maybe it's trying to use some virtualization feature that Fedora disables by default? No idea... way outside of my knowledge base.

[Spirrwell]

Ah yep, it's to do with SELinux. I disabled it and now it works. But the newer runtimes like Soldier work out of the box, so I don't understand why this is an issue.

[smcv]

The scout runtime has an ancient version of dpkg (scout is based on Ubuntu 12.04, from 2012, so it's literally a decade old at this point), so it's entirely possible that it's doing something that would have made sense in 2012 but is no longer useful or reasonable in 2022.

As a guess, maybe the newer versions in soldier/sniper are able to detect that they're in an unprivileged or less-privileged container environment and not try to talk to system-wide SELinux services outside the scope of the container, but the older version in scout doesn't know about containers (which weren't really a thing yet in 2012!) and tries to talk to system-wide SELinux services anyway?

It might be possible to avoid this by rebuilding scout's dpkg with SELinux support disabled, so that it always behaves as though your host system wasn't using SELinux (like it would on an OS that uses a non-SELinux LSM, like Debian or Ubuntu, or on an OS that doesn't use a "big" LSM at all, like Arch).

My knowledge of containers is that they are basically VM's, but not quite... Still, I thought the point of running builds in them was to isolate them from the host system

"but not quite" is doing a lot of work in that sentence! Not every Linux kernel feature is namespaced, unfortunately. Some things (including SELinux) don't have namespacing, so the only options are to let the container talk to the "real" system feature (which would usually be insecure) or to make talking to the "real" system feature fail with an error (which is secure, but can break non-container-aware programs in the container).

Workaround: run your container in a VM whose operating system doesn't use SELinux (for instance Debian, Arch or Ubuntu - basically anything other than Fedora and CentOS).

[slembcke]

Well, for my own uses, I just changed up how my builds work so that my resources and Windows executable get built in one container, and just the Linux executable gets built in the Scout one. That way I don't need to install anything extra. I'd consider this closed if there was a short note somewhere on the readme that it "doesn't work with SELinux hosts such as Fedora" or something.

[smcv]

In your Fedora environment, does a selinuxfs filesystem show up in /proc/mounts inside the Docker/Podman container? It looks as though that's the mechanism that dpkg uses to decide whether it should do SELinux things.

[Spirrwell]

Apologies this took so long for me to get back to you. I ended up having to reinstall Fedora to re-enable SELinux for some reason.

Anyway, I assume the way you check that is doing cat /proc/mounts? In which case I don't see selinuxfs for either Scout or Soldier.

EDIT: For what it's worth, I do see selinux inside /sys/fs though I don't know how this all works together or if this is relevant.

[smcv]

@kisak-valve, please could you retitle this to "Can't install packages in scout container on SELinux (Fedora) system"?

I can reproduce this on Fedora 36. A simple reproducer:

$ podman run --rm -it registry.gitlab.steamos.cloud/steamrt/scout/sdk:beta
(steamrt scout 0.20220802.0)root@HASH:/# dpkg-query -W dpkg
dpkg    1.17.5ubuntu5.8+steamrt1.1+srt2
(steamrt scout 0.20220802.0)root@HASH:/# apt-get download base-files
(steamrt scout 0.20220802.0)root@HASH:/# dpkg -i base-files_*.deb

In the similar soldier container (with dpkg 1.19.8) this works as expected. We can probably work around this by rebuilding scout's dpkg with SELinux disabled: scout is based on Ubuntu, which is based on Debian, which supports using SELinux system-wide, but scout is not designed to be used as a whole OS (only as a container or a LD_LIBRARY_PATH runtime) so there's no point in it having LSM support.

[smcv]

I think this is happening because scout's libselinux is sufficiently ancient that it doesn't have https://github.com/SELinuxProject/selinux/commit/c08c4eacab8d55598b9e5caaef8a871a7a476cab. Updating core packages like dpkg in a 10 year old codebase is always a bit alarming, so it might actually be lower-risk to backport that change to libselinux; that's on my queue to test.

[smcv]

it might actually be lower-risk to backport that change to libselinux

This seems to work well, so that change is queued for a future scout update.

[smcv]

This should be fixed in the scout beta SDK version 0.20221019.0, available by pulling the Docker/Podman image registry.gitlab.steamos.cloud/steamrt/scout/sdk:beta. Please could someone on Fedora confirm that?

Please note that games compiled in the beta SDK are not guaranteed to work with the general-availability Steam client, so you can use registry.gitlab.steamos.cloud/steamrt/scout/sdk:beta for development, but games released to the public should be compiled in the stable version registry.gitlab.steamos.cloud/steamrt/scout/sdk:latest, or a specific pinned version like registry.gitlab.steamos.cloud/steamrt/scout/sdk:0.20220802.0.

This means that if you're releasing games to the public, you'll need to use a workaround until the general-availability branch of Steam picks up this updated SDK. Some possible workarounds:

• avoid needing to install new apt packages for your scout build, similar to https://github.com/ValveSoftware/steam-runtime/issues/528#issuecomment-1252465736
• run your scout builds on a non-Fedora OS (perhaps Debian or Ubuntu), possibly in a virtual machine
• run your scout builds on a machine with SELinux disabled

[slembcke]

Thanks for looking into this. I also want to add that I appreciate how easy the Scout SDK makes it to build my stuff. :) I've worked on quite a few platforms over the years, and setting up the automation for this was quite low on the difficulty scale.

[Spirrwell]

Sorry for the delay again. But the beta does work perfectly fine in podman, apt-get install works!

I'm actually getting new issues when using the docker image on Fedora (both latest and beta). This feels more like a Fedora issue, but apt-cache search, apt-get install just sort of freeze until I interrupt with Ctrl+C. Again this feels more like a Fedora issue. I just did a fresh installation, and it's possible I'm on a buggy update.

[kisak-valve]

Closing per the last couple comments.

@Spirrwell, please open a separate issue report if you want help pondering your follow up issue.