Annotation "io.podman.annotations.seccomp" has no effect

[MaxKellermann]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Annotation io.podman.annotations.seccomp=unconfined has no effect. The setting shows up in inspect:

            "SecurityOpt": [
                "seccomp=unconfined"
            ],

This is the same output which also appears when I create the container with --security-opt=seccomp=unconfined. With the command line option, io_uring system calls work, but with just an annotation in the image manifest, io_uring system calls are blocked.

Steps to reproduce the issue:

1. Create OCI image with the following in the manifest: {"annotations": {"io.podman.annotations.seccomp": "unconfined"} ...

2. Run container without --security-opt=seccomp=unconfined

3. Try to use any io_uring system call

Describe the results you received:

All io_uring system calls fail with EPERM because they were blocked with seccomp.

Describe the results you expected:

All io_uring system calls should succeed.

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

Output of podman version:

Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.17.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 20
  distribution:
    codename: bullseye
    distribution: debian
    version: "11"
  eventLogger: journald
  hostname: heron
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.7-heron
  linkmode: dynamic
  logDriver: journald
  memFree: 2294554624
  memTotal: 33572904960
  ociRuntime:
    name: runc
    package: 'runc: /usr/bin/runc'
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0~rc93+ds1
      commit: 1.0.0~rc93+ds1-5+b2
      spec: 1.0.2-dev
      go: go1.15.9
      libseccomp: 2.5.1
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: ""
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.4.0
  swapFree: 68472975360
  swapTotal: 68719472640
  uptime: 186h 28m 12.35s (Approximately 7.75 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 7
    paused: 0
    running: 0
    stopped: 7
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.2
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/amd64
  Version: 3.4.2

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

podman/testing,unstable,now 3.4.2+ds1-1 amd64 [installed]
podman/testing,unstable 3.4.2+ds1-1 i386

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

No.

I have tested Podman 3.0.1 (Debian Bullseye) and 3.4.2 (Debian Unstable), but not the latest version.
There is nothing relevant in the troubleshooting guide.

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

Debian Bullseye + Unstable.

[rhatdan]

@vrothberg Is this defined in the OCI Spec?

Personally I don't believe that there should be anything in the image that can cause containers to run with less privilege, unless the caller to the container engine wants to "trust" the image.

@MaxKellermann are you saying the Docker works with this annotation? Kubernetes?

[vrothberg]

@vrothberg Is this defined in the OCI Spec?

No that's our custom way of shipping seccomp profiles with images. I don't think that unconfined is a supported value though.

I can have a look tomorrow.

[vrothberg]

@MaxKellermann are you saying the Docker works with this annotation? Kubernetes?

It's a Podman-specific feature.

[MaxKellermann]

No, I'm not saying that. I have never used Docker, and this is a podman-specific annotation. Like all annotations, it is undocumented.

This annotation showed up in podman inspect when the container was launched with --security-opt=seccomp=unconfined, so I tried adding this annotation to the OCI image manifest, and it showed up the same way without that command-line option, and it showed up the same way in SecurityOpt.

Maybe my "reverse-engineered" wisdom is wrong, and then this can be closed. But I'm pretty lost with the Podman documentation; any time I'm looking for something, there's no word about it in the documentation, so I started looking for clues in how it really works.

[MaxKellermann]

No that's our custom way of shipping seccomp profiles with images. I don't think that unconfined is a supported value though.

Where can I find documentation on what values for this annotations are legal, and how can I allow my container to use io_uring? That's all I really want.

[rhatdan]

The idea of this flag, was to allow a user to set a subset of seccomp rules to allow, Less then the default. So setting unconfined would not be allowed by default. (Not sure if this feature was ever fully implemented.)

[vrothberg]

Where can I find documentation on what values for this annotations are legal, and how can I allow my container to use io_uring?

The annotation is undocumented since we don't want to promote this feature yet. There's some ongoing work to make it more usable and once merged, we'll add documentation and promote it.

--security-opt=seccomp=unconfined is the way to go if you want to disable a seccomp filter.

[MaxKellermann]

Tried searching the documentation for "annotation": https://docs.podman.io/en/latest/search.html?q=annotation
But none of the search result show which annotations are possible, and none explains this annotation. (This is what I meant when I said I'm lost in the documentation.)

[MaxKellermann]

The idea of this flag, was to allow a user to set a subset of seccomp rules to allow, Less then the default. So setting unconfined would not be allowed by default. (Not sure if this feature was ever fully implemented.)

If an unsupported value is specified, I'd expect podman to fail with an error, instead of promoting the (unsupported and actually unused) value straight into the "inspect" command. If I see something in "inspect", I expect it to work. Maybe, after clearing up that what I try to do isn't supposed to work, this is the remaining bug - just an error handling bug.

[rhatdan]

I agree, although, it should probably print a warning. I would not want to block users from using an image, that was created incorrectly.

[vrothberg]

OK, it is documented (see https://github.com/containers/podman/blob/main/docs/source/markdown/podman-create.1.md#--seccomp-policypolicy) but the annotation is a different one: io.containers.seccomp.profile

I'll take a look now what io.podman.annotations.seccomp is meant to do.

[vrothberg]

I'll take a look now what io.podman.annotations.seccomp is meant to do.

The annotation is only set when a container has been created with a custom seccomp profile (or unconfined) and it is only used in podman inspect.

[vrothberg]

Here's a PR to clarify the semantics: #12679

As mentioned in #12671 (comment), the correct label to use in the image is io.containers.seccomp.profile which will be applied when the seccomp policy is set to image.

Previous statements from me above were incorrect (e.g, re: undocumented etc.).

[MaxKellermann]

Thanks @vrothberg, that is an improvement - but one issue remains: if specified in the container manifest, the io.podman.annotations.seccomp annotation shows up twice in podman inspect, once in the annotation list and again in SecurityOpt. Reflecting that (invalid) input value strongly suggests that Podman has accepted it and uses it, but that's not the case.
I wish to have two things, to avoid confusing users:

• if a value was not accepted, don't show it in inspect
• if a value was not accepted, either print a warning or abort with an error

[vrothberg]

Let me see what I can do. Podman is applying the annotations from the image to the container, which explains why the annotation is shown there.

[vrothberg]

Added another commit to #12679 to prevent Podman from applying "reserved" annotations from the image to the container.