Could they just take the container-selinux upstream package and install/compile that and see if it fixes their problem.  If yes then just use this policy.

I will try this in my test env first, which version do you suggest I try? I tried 2.165, but on a R8 system, this created quite the headache in dependency resolutions to be manually resolved. 

This does not work on the latest RHEL8.4 update which has container-selinux-2.158.0-1.module+el8.4.0+10607+f4da7515.noarch, is there a reason you think a lower version upstream would get this working?

I just got this working on my laptop.

https://github.com/containers/container-selinux/releases/tag/v2.163.0

Could you download and compile the policy to see if it works for you.

This will be in the next RHEL release of container-selinux policy.

Wayah, could you try Dan's fix please?

In the mean time, I'm going to set this to post and hand it off to Jindrich for packaging needs.

@dwalsh Can you provide me with a build for this? I attempted to make a scratch-build but it's still not working for me after using the newer version.

If this is failing for scratch builds, then it should be the same,  What AVCs are you seeing?

Perhaps we can work on this together, next week.  I got it working on my laptop, but I am not sure how robust it is.

Can you just patch out that line.  This is a difference between Upstream selinux-policy and RHEL8.

I can certainly do it. It makes me thinking, would it make sense to create RHEL branch for container-selinux too? This is the second thing we need to maintain downstream which would become messy over time.

The first one is http://pkgs.devel.redhat.com/cgit/rpms/container-selinux/tree/rhel-fix.patch?h=stream-container-tools-rhel8-rhel-8.5.0&id=ad778a796ff386322f8d987e1d54d80c399703e2

Yup either way it gets messy.  Could you open a PR for container-selinux to add it upstream?

Confirming removing that line fixes the RHEL8.5 build. Can we get qa ack here please?

Fair enough, let's wait for the third build fix and I will do a PR upstream :-)

I actually think it would be best for us to look at changing the way the podman works. IE To stop using system_r and system_u, and start using the calling programs user and role.

Could you try to add 

podman run --security-opt label=user:user_u --security-opt label=role:user_r ...

And see if this solves the problem for you?

Dan, I got the below error when I try to run this command.

[john2@kvm-02-guest05 ~]$ podman run --security-opt label=user:user_u --security-opt label=role:user_r -it registry.access.redhat.com/rhel7 sleep 20
Error: OCI runtime error: container_linux.go:370: starting container process caused: process_linux.go:459: container init caused: failed to set /proc/self/attr/keycreate on procfs: write /proc/self/attr/keycreate: invalid argument

Is it because podman is too old? I have the same container-tools version as the reporter has,
[john2@kvm-02-guest05 ~]$ podman info
host:
  arch: amd64
  buildahVersion: 1.18.0
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.22-3.module+el8.3.1+9857+68fb1526.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.22, commit: a40e3092dbe499ea1d85ab339caea023b74829b9'
  cpus: 1
  distribution:
    distribution: '"rhel"'
    version: "8.3"
  eventLogger: file
  hostname: kvm-02-guest05.rhts.eng.brq.redhat.com
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1002
      size: 1
    - container_id: 1
      host_id: 231072
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1002
      size: 1
    - container_id: 1
      host_id: 231072
      size: 65536
  kernel: 4.18.0-240.22.1.el8_3.x86_64
  linkmode: dynamic
  memFree: 1678761984
  memTotal: 3920019456
  ociRuntime:
    name: runc
    package: runc-1.0.0-70.rc92.module+el8.3.1+9857+68fb1526.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.2-dev'
  os: linux
  remoteSocket:
    path: /run/user/1002/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.module+el8.3.1+9857+68fb1526.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 4257214464
  swapTotal: 4257214464
  uptime: 17h 16m 8.59s (Approximately 0.71 days)
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/john2/.config/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 0
    stopped: 4
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.3.0-2.module+el8.3.1+9857+68fb1526.x86_64
      Version: |-
        fusermount3 version: 3.2.1
        fuse-overlayfs: version 1.3
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/john2/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/user/1002/containers
  volumePath: /home/john2/.local/share/containers/storage/volumes
version:
  APIVersion: "2"
  Built: 1612819146
  BuiltTime: Mon Feb  8 22:19:06 2021
  GitCommit: ""
  GoVersion: go1.14.7
  OsArch: linux/amd64
  Version: 2.2.1

What AVCs are you seeing?

----
time->Mon Jun 28 10:25:19 2021
type=USER_AVC msg=audit(1624868719.321:235): pid=940 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  received policyload notice (seqno=2)  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Mon Jun 28 10:25:34 2021
type=USER_AVC msg=audit(1624868734.500:236): pid=940 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  received policyload notice (seqno=3)  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Mon Jun 28 10:26:58 2021
type=USER_AVC msg=audit(1624868818.190:301): pid=940 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  received policyload notice (seqno=4)  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

Those are not AVCs (Well denied AVCs anyways.)

I think this is an out of date runc.

Based on Dan's last comments, I'm setting this back to ON_QA.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: container-tools:rhel8 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:4154