mc-image-helper get subcommand causes SELinux quirkiness

[virtualdxs]

Apologies in advance, I am struggling to comprehend how SELinux categories are supposed to work.

I have an Oracle Linux 8 box, on which I'm using podman with docker-compose to bring up a Spigot server with a few spiget plugins. It seems that when I stop the container, make changes to my docker-compose.yml, and start it again, the container gets permission denied on the first plugin version.json file. (I haven't 100% nailed down what reproduces it yet.) I tracked down the issue and determined that all files downloaded from spiget have SELinux categories on them:

-rw-rw-r--. 1 20003 root system_u:object_r:container_file_t:s0:c40,c562    17870 Apr 22 05:54 83661.jar
-rw-rw-r--. 1 20003 root system_u:object_r:container_file_t:s0:c40,c562    29256 Apr 22 05:54 86391.jar
-rw-rw-r--. 1 20003 root system_u:object_r:container_file_t:s0:c40,c562    85928 Apr 22 05:54 91537.jar
-rw-rw-r--. 1 20003 root system_u:object_r:container_file_t:s0:c40,c562  2219573 Apr 22 05:54 97320.jar
drwxrwxr-x. 5 20003 root system_u:object_r:container_file_t:s0               199 Apr 22 05:54 BedWars1058
drwxrwxr-x. 2 20003 root system_u:object_r:container_file_t:s0                24 Apr 22 05:54 bStats
drwxrwxr-x. 2 20003 root system_u:object_r:container_file_t:s0                24 Apr 22 05:54 PluginMetrics
-rw-r--r--. 2 root  root unconfined_u:object_r:container_file_t:s0      10464701 Dec  7 05:56 slimeworldmanager-plugin-2.2.1.jar

Note the :c40,c562 on the top 4, and the lack thereof on the 3 folders below (created by the container) and the bottom plugin (created manually). This is confirmed to most likely be the issue by audit2why:

#       Possible cause is the source level (s0:c30,c433) and target level (s0:c40,c562) are different.

Unfortunately, I was not able to determine what causes files to be created with or without categories.

Please let me know if you need more information, or if I should have filed this under itzg/docker-minecraft-server instead.

[itzg]

Can you provide the compose file you're using? I'm wondering what you have set to cause the files to be owned by root. The container logs would also be helpful.

(Yes, this issue belongs in itzg/docker-minecraft-server, but I can move it over later)

[virtualdxs]

To clarify, the ones owned by user root are like that because I copied them there as root. All files created by the container are owned by uid 20003 (but still group 0).

docker-compose.yml:

services:
  minecraft:
    image: itzg/minecraft-server
    user: "20003"
    ports:
      - 32703:25565
    volumes:
      - ./data:/data
    environment:
      EULA: "true"
      TYPE: SPIGOT
      VERSION: 1.8.8-R0.1-SNAPSHOT-latest
      SPIGET_RESOURCES: 97320,83661,86391,91537
      JVM_OPTS: '-javaagent:slimeworldmanager-classmodifier-2.2.1.jar'
    tty: true
    stdin_open: true

[itzg]

If you're copying files in as root, then you have probably created your own permissions conflict. Look through your ./data directory and get things consistent to uid 20003.

[virtualdxs]

The files that are owned by root are not the problem, it's files owned by 20003 with the SELinux categories set. I'll go ahead and make everything consistent but it's had no issues reading the things owned by root.

[virtualdxs]

Reproduced with no root-owned files in the data directory. Procedure:

1. Create data dir owned by 20003 and with selinux label set to container_file_t
2. Create docker-compose.yml with the following:

services:
  minecraft:
    image: itzg/minecraft-server
    user: "20003"
    volumes:
      - ./data:/data
    environment:
      EULA: "true"
      TYPE: SPIGOT
      VERSION: 1.8.8-R0.1-SNAPSHOT-latest
      SPIGET_RESOURCES: 97320,83661,86391,91537
      FOO: bar
    tty: true
    stdin_open: true

3. Run docker-compose up
4. Wait until (at least) the spiget resources have downloaded
5. Press Ctrl+C
6. Add an environment variable to docker-compose.yml (I added FOO: bar)
7. Wait 5 minutes (minimum duration between checking spiget resources)
8. Run docker-compose up

Output:

minecraft_1  | [init] Running as uid=20003 gid=0 with /data as 'drwxrwxr-x. 7 20003 0 4096 Apr 22 16:27 /data'
minecraft_1  | [init] Resolved version given 1.8.8-R0.1-SNAPSHOT-latest into 1.8.8-R0.1-SNAPSHOT-latest
minecraft_1  | [init] Resolving type given SPIGOT
minecraft_1  | [init] Downloading Spigot from https://cdn.getbukkit.org/spigot/spigot-1.8.8-R0.1-SNAPSHOT-latest.jar ...
minecraft_1  | [init] Getting plugins via Spiget
minecraft_1  | [init] Downloading resource 97320 ...
minecraft_1  | jq: error: Could not open file /data/plugins/.97320-version.json: Permission denied

[itzg]

Thanks for the logs. That confirms the process is running as the user/group you intended. You can add DEBUG: "true" to see exactly the shell command creating those version json files. There's nothing special about the file operations.

I'm afraid there's nothing else I know to do. I have been lucky in my career to mostly stay far away from SElinux.

[itzg]

...oh, you could ask on the Discord server if anyone is running with SElinux enabled.

Also, I seem to remember a permissive mode that can be enabled to know what security rules would satisfy SElinux.

[virtualdxs]

Good news and bad news.

Good news: I figured out the issue. It should be reproducible in any environment that uses podman (I don't think docker has this behavior, but not certain) and SELinux.

Podman sets these categories on containers' root directories (via mount options) in order to prevent a malicious process that escapes its container from being able to access other containers' data. Volumes do not have these categories set because they are expected to need to be accessed either concurrently by multiple containers (with different categories), or in the future by a different container (due to the disposable container philosophy).

This image downloads spiget resources to /tmp. In this image, /tmp is simply a folder within the root partition. Therefore, it has the categories applied. Then, when it moves the resource from /tmp to /data, those categories are preserved.

Bad news: I'm not sure there's a clean fix without making the image SELinux-aware. Options I'm brainstorming:

• Copy and delete instead of move
  Copying does not preserve categories as it creates a new file in the destination, which does not have mount option for the categories set. Downside is it takes more time and potentially adds unnecessary disk io. (Potentially because it wouldn't add any extra if data were on a different filesystem than container root storage).
• Document that on systems with podman and SELinux /tmp must be mounted as a volume
  Volumes do not have categories set (just tested, neither bind mounts nor named volumes have categories), so if /tmp were a volume the categories would never be set in the first place. Downsides are added complexity and more persistence than expected
• Download to a temporary file in the plugins directory rather than /tmp
  Similar to above, if it's downloaded directly onto a volume the categories will never be set. This might be the way to go, but I might be missing a downside. Would this be a workable option?

[virtualdxs]

I should note I'm happy to fix it myself and open a PR, just want to make sure you'd be happy with merging the fix before I dump all that effort into it.

[itzg]

Good find! I like bullet three since it keeps all the relevant filesystem access to the volume. A PR would be great.

[virtualdxs]

Opened #1486. Tested with the above procedure; spiget files are correctly created without SELinux categories, and thus are accessible by future containers.