fix: Containers - Bind Mounts - Security and Compatibility (Docker / Podman / SELinux) for Fetch, Git, and Time Servers

[trentapple]

The following includes patches to docker files for existing servers.

• fetch
• git
• time

Description

Unshared and private label limiting access to only the current container on bind mount files (Z) referenced by Dockerfile RUN. This allows the container to be used with a podman and SELinux configuration. Without it, the build fails due to the security system (SELinux) blocking attempts to use bind mounted content /app/pyproject.toml (and eventually /app/uv.lock).

Resources:

• https://developers.redhat.com/articles/2025/04/11/my-advice-selinux-container-labeling
• https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-6-use-linux-security-module-seccomp-apparmor-or-selinux
• https://docs.docker.com/engine/storage/bind-mounts/#configure-the-selinux-label

Server Details

• Server: fetch, git, time
• Changes to: Dockerfile

Motivation and Context

It improves compatibility / accessibility and enables security enhancements for hardened container environments.

Ultimately, the motivation is to allow using MCP servers with docker / podman on hosts that have SELinux container separation enabled and enforcing (default for podman). See also: rule 6 from OWASP security cheat sheet.

Additionally, one of the base images does not have the user / group “app” currently which is being used with a --chown that fails. This is secondary to the purpose of this PR, but app:app may need to exist in order for the build step to succeed in a fresh environment.

How Has This Been Tested?

Docker / Podman build on the Dockerfile in question. Then the built images were run as integrations for a customized LLM client / frontend.

Under src/fetch directory
podman build -t mcp/fetch .

Under src/time directory
podman build -t mcp/time .

Under src/git directory
podman build -t mcp/git .

The container build commands now succeed for docker / podman with security systems that are configured to handle containers.

Breaking Changes

No known / identified breaking changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

LLM client test done with mcpo Dockerfile that is setup to include the artifacts from the built mcp/time. Then this was included as a full OpenAPI spec in tools for the local LLM client in use (see screenshot for end result).

For the missing user/group scenario, consider approach from DoD’s iron bank container for python312 which (at the time of writing this) explicitly creates a group / user with the ID (1001).

[trentapple]

These are the only three servers which needed an updated Dockerfile in order to work in secure environments.

[trentapple]

Relevant to missing app user/group in base image astral-sh/uv-docker-example/issues/29. Some environments may ignore (and without these changes it is possible to end up with root:root ownership), but the change is written to consistently succeed regardless.

I noticed @astral-sh currently do not use that --chown app:app in the Dockerfile, but it is in the standalone.Dockerfile and multistage.Dockerfile of uv-docker-example.

As it relates to SELinux and/or OWASP container guidance — there seems to be minimal risk with these changes and it enables greater accessibility / security in certain environments. Per the article by @rhatdan:

SELinux has blocked most of the container breakout scenarios from the past decade-plus

I noticed that ramalama took a comprehensive (more enterprise-friendly) approach to installing uv, but that may not be applicable here.

This is helpful in multiple scenarios, but YMMV.