New podman version introduce new issue with selinux and relabelling: relabel failed "/run/netns": operation not supported

[cjeanner]

kind bug

Description

With latest podman release (see bellow), we encounter an issue when we mount /run/netns with "z,shared" flags:

relabel failed "/run/netns": operation not supported

Steps to reproduce the issue:

1. Create some network namespace in order to ensure /run/netns exists

2. Create a container with /run/netns mounted as a volume (--volume /run/netns:/run/netns:z,shared)

Describe the results you received: The container crashes with an error on the relabelling of /run/netns

Describe the results you expected: It should start the container and proceed to the relabelling.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:       0.12.1.2
Go Version:    go1.10.2
OS/Arch:       linux/amd64

Output of podman info:

host:
  BuildahVersion: 1.6-dev
  Conmon:
    package: podman-0.12.1.2-2.git9551f6b.el7.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 97d5f1232f62307696c8b4b2d430e8b771a45873-dirty'
  Distribution:
    distribution: '"centos"'
    version: "7"
  MemFree: 755589120
  MemTotal: 8364449792
  OCIRuntime:
    package: runc-1.0.0-57.dev.git2abd837.el7.centos.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.0'
  SwapFree: 3376672768
  SwapTotal: 8588881920
  arch: amd64
  cpus: 8
  hostname: undercloud.localdomain
  kernel: 3.10.0-957.1.3.el7.x86_64
  os: linux
  rootless: false
  uptime: 1h 53m 11.26s (Approximately 0.04 days)
insecure registries:
  registries:
  - 192.168.24.1:8787
  - 192.168.24.3:8787
registries:
  registries:
  - registry.centos.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  ContainerStore:
    number: 88
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 35
  RunRoot: /var/run/containers/storage

Additional environment details (AWS, VirtualBox, physical, etc.):

[cjeanner]

@EmilienM I took the liberty to open this one ;). If you have some other things to add, feel free to do so.

[rhatdan]

Since /run/netns mount does not support labeling, remove the :z. Should fix the issue.

What is the label on /run/netns?

ls -lZd /run/netns

[cjeanner]

Hello @rhatdan Thanks for your quick answer. The labels (before anything is done with podman or whatever) are:

drwxr-xr-x. root root unconfined_u:object_r:ifconfig_var_run_t:s0 netns/

We have containers that are actually using netns, for creation, removal and global management, and this directory is mounted in multiple containers. That's why I used the ":z" flag - maybe the "shared" will be enough?

Cheers,

C.

[rhatdan]

Well that is the label of the directory, but the contents of the directory seem to be process labels of the process that created the network namespace.

I see unconfined_t and container_runtime_t.

I believe the container_t process should be allowed to read those.

[cjeanner]

Hmm ok. So here's the labels for the content of netns:

ls -lZ netns/
-r--r--r--. root root system_u:object_r:proc_t:s0      removeme

This is a namespace created from the host directly. For now I don't have the right process creating the namespaces - I need to patch my code locally in order to drop the ":z", else it won't work as podman will reject that flag and make an error.

We already pushed some patches in our CI in order to get rid of those "z" flags, and apparently it seems to work, at least we can deploy the app - now we have to ensure all related containers can access that directory, and manage the namespaces in it. That's another story.

I'll keep this issue updated accordingly.

[EmilienM]

@cjeanner have you manually tested the changes in tripleo with selinux enforced? (I haven't yet)

[cjeanner]

@EmilienM it's on the bench right now with under + overcloud deploy.

[cjeanner]

@rhatdan ah, forgot to say, it's on a permissive environment… podman shouldn't try to relabel things on a permissive env, should it? I'm not sure docker actually tries that…

[cjeanner]

@EmilienM so once the patches are applied, I get my containers running with the netns mount, and apparently it's working as expected.

@rhatdan so basically, this seems to be once again the issue that podman tries to relabel things on a non-SELinux enabled system. I think we already hit that in the past.

[EmilienM]

Thanks Cedric, that's good news. We'll probably be able to restore podman in our CI asap.

On Fri, Dec 21, 2018, 10:32 AM Cédric Jeanneret <notifications@github.com wrote:

@EmilienM https://github.com/EmilienM so once the patches are applied, I get my containers running with the netns mount, and apparently it's working as expected.

@rhatdan https://github.com/rhatdan so basically, this seems to be once again the issue that podman tries to relabel things on a non-SELinux enabled system. I think we already hit that in the past.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/containers/libpod/issues/2034#issuecomment-449352081, or mute the thread https://github.com/notifications/unsubscribe-auth/ABnCoRkojWwEgBPHf4knGG3oFoZYqIGTks5u7LjCgaJpZM4Zb_R0 .

[rhatdan]

Permsisive does not mean Disabled. All SELinux actions will take place and only actions denied by SELinux AVC messages will be allowed. Any activity like relabeling, is still going to be blocked if it is not supported.

[rhatdan]

@cjeanner This is a case where the file system does not support SELinux XAttr labeling. So the kernel denies the label. In those cases we have three choices 1: Attempt to mount the file system with a context="LABEL" flag so we treat the entire mount point with a single label 2: we use the default labels contained in the file system and make changes to containers to be able to use these labels 3: Disable SELinux separation.

[cjeanner]

@rhatdan Thanks for your explanations! I think the patches we made in our project are working, we just dropped the "z" flag while keeping "shared", and apparently it allowed the whole thing to work. And one of the two patches involved in our code is merged.

So I close this one, and will try to keep your explanations in mind for the next time we hit this kind of issue. Hopefully it's the last one we hit :/.

Thanks again!