/sys/fs/selinux gets mounted in rootless mode when both '--network host' and '--privileged' are used

[debarshiray]

/kind bug

Description

Looks like containers/toolbox#47 has raised its head again.

An instance of selinuxfs is getting mounted at /sys/fs/selinux when both --network host and --privileged are used.

Compare:

$ podman run --interactive --tty --rm registry.fedoraproject.org/fedora:31 ls /sys/fs/selinux
$ podman run --interactive --network host --privileged --tty --rm registry.fedoraproject.org/fedora:31 ls /sys/fs/selinux
...
...

Output of podman version:

Version:            1.6.2
RemoteAPI Version:  1
Go Version:         go1.13.1
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.1
  podman version: 1.6.2
host:
  BuildahVersion: 1.11.3
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.1-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.1, commit: 5e0eadedda9508810235ab878174dca1183f4013'
  Distribution:
    distribution: fedora
    version: "31"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 1265209344
  MemTotal: 8113770496
  OCIRuntime:
    name: crun
    package: crun-0.10.2-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.2
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 4051955712
  SwapTotal: 4133482496
  arch: amd64
  cpus: 4
  eventlogger: journald
  hostname: kolache
  kernel: 5.3.5-300.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 6h 26m 23.38s (Approximately 0.25 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/rishi/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.6.5-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.6.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/rishi/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 2
  RunRoot: /run/user/1000
  VolumePath: /home/rishi/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.6.2-2.fc31.x86_64

[martinpitt]

Thanks @debarshiray for your detective work!

[giuseppe]

personally I'd prefer to solve it with something like --mount type=tmpfs,target=/sys/fs/selinux but we need a way to disable tmpcopyup from the options otherwise it cannot be used for this specific case.

[giuseppe]

I've opened a PR to add support for notmpcopyup: #4466

[rhatdan]

What is the problem you are trying to solve? Why is /sys/fs/selinux getting mounted when --privileged?
This would seem to be a problem in that libselinux would start to act on the fact that selinux is enabled and could get permission denied trying to set xattrs.

[giuseppe]

the feature I've added is more generic, we currently have no way to disable tmpcopyup. It is fine to use it by default, but there should be a way to mount an empty tmpfs

[rhatdan]

Agree, I like your PR, I am just asking why we are mounting this and what trouble it is causing.

[giuseppe]

I am just asking why we are mounting this and what trouble it is causing

I've not verified but that can be an effect of bind mounting /sys (since we cannot mount a new instance with --network host) and skipping masked paths when --privileged is used.

I don't think we should treat /sys/fs/selinux different than other masked paths. If --privileged is used and that path must be masked, then it should be done explicitly.

[cgwalters]

FWIW cgwalters/coretoolbox@3c74c64

[rhatdan]

Makes sense.

[debarshiray]

I am just asking why we are mounting this and what trouble it is causing

[...]

I don't think we should treat /sys/fs/selinux different than other masked paths. If
--privileged is used and that path must be masked, then it should be done explicitly.

This is now fixed in Toolbox with containers/toolbox#337

I am wondering if this should still be fixed in Podman itself, or is it so that --network host --privileged implies that /sys/fs/selinux would have a selinuxfs instance?

[rhatdan]

The issue is if someone wanted to SELinux stuff from a process within a container, we need the process to know that SELinux is enabled.