Podman: Error: invalid config provided: AppArmorProfile and privileged are mutually exclusive options

[polygamma]

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

/kind bug

Description

sudo podman run --privileged hello-world leads to

Error: invalid config provided: AppArmorProfile and privileged are mutually exclusive options

when using Ubuntu 20.04.

I was informed by a colleague of mine about this problem, when he tried to use an image of us, and could not get it to work.

Using Arch Linux, I could not reproduce the problem.

Steps to reproduce the issue:

To reproduce it, I installed Ubuntu 20.04 in a VirtualBox VM where the error appears, too.

1. Download the latest Ubuntu 20.04 image from https://releases.ubuntu.com/20.04/ and install Ubuntu 20.04 in a VirtualBox VM

2. Update the system and install curl: sudo apt-get update && sudo apt-get dist-upgrade && sudo apt-get install curl

3. Install Podman

source /etc/os-release
sudo sh -c "echo 'deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_${VERSION_ID}/Release.key | sudo apt-key add -
sudo apt-get update
sudo apt-get install podman

1. Run the command sudo podman run --privileged hello-world and get the error.

I want to explicitly state at this point, that I did nothing else, besides updating the system, installing curl and installing Podman.

Describe the results you received:

I could not run the hello-world image when using sudo and --privileged.

Describe the results you expected:

I want to be able to run the hello-world image, even when using sudo and --privileged.

Output of podman version:

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

Output of sudo podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.0
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.18, commit: '
  cpus: 1
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: file
  hostname: jonny-ubuntu-vm
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.4.0-40-generic
  linkmode: dynamic
  memFree: 2601410560
  memTotal: 4127621120
  ociRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 1426522112
  swapTotal: 1469710336
  uptime: 1h 25m 6.08s (Approximately 0.04 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  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: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.2
  OsArch: linux/amd64
  Version: 2.0.2

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

Listing... Done
podman/unknown,now 2.0.2~1 amd64 [installed]
podman/unknown 2.0.2~1 arm64
podman/unknown 2.0.2~1 armhf
podman/unknown 2.0.2~1 s390x

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

Has already been described.

[alitvak69]

This is reproduced on ubuntu by ceph users.

#

Hi,

Using the repo suggested for Ubuntu 18 (
https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_18.04/
) podman 2.0.2~1 is installed. However, when attempting to use cephadm to
bootstrap a cluster, we see an error when attempting to start the mon
container:

"Error: invalid config provided: AppArmorProfile and privileged are
mutually exclusive options"

From the bit of reading we've done, this looks to be an issue with Podman
v2 compatibility, and it appears to break with Ceph 15.2.4.

Has anybody else run into this/been able to workaround it? We'll have to
downgrade podman, but unfortunately, that repo does not keep previous
versions.

[ormandj]

Correct, that was my post, and it does occur on Ubuntu 18.

[mheon]

Is the expectation that the apparmor profile will be applied and used, or discarded? With SELinux + --privileged we will honor the --security-opt request for a specific label, so I lean towards doing that, but Podman 1.9 compatibility is more important.

[alitvak69]

@mheon I am not sure if any policy specific to podman is configured in many cases.
Containers.conf has default entry commented out:

# Used to change the name of the default AppArmor profile of container engine.
#
# apparmor_profile = "container-default"

And 1.9.3 and below just run --privileged without any --security-opt. Podman 2.0.2 exibits the same error with --security-opt

# podman run --privileged --security-opt=apparmor=unconfined hello-world
Error: invalid config provided: AppArmorProfile and privileged are mutually exclusive options

[rhatdan]

--privileged should not enable apparmor. containers.conf is showing you the defaults. It is built into the code. If you want to change the default you can uncomment and change that line, otherwise it will apply apparmor policy on systems that support apparmor.

If a user says --privileged --security-opt apparmor=/etc/myapparmor
Then the my apparmor policy should be applied and everything else be privileged. We just fixed this issue with SELinux as @mheon pointed out.

[polygamma]

Based on

A privileged container turns off the security features that isolate the container from the host. Dropped Capabilities, limited devices, read-only mount points, Apparmor/SELinux separation, and Seccomp filters are all disabled.

Source: http://docs.podman.io/en/latest/markdown/podman-run.1.html

would I assume, that AppArmor profiles would be discarded. Sounds like you want to change that now, so that you can use AppArmor and privileged together?

Should one really do that, change the meaning of privileged so drastically? Sounds more like one wanted to introduce a new option for that e. g. privileged-drop that allows dropping of security features to be deactivated.

And for my understanding: As it seems to be implemented now, the default AppArmor profile is container-default when not having touched any config like containers.conf and thus conflicts with privileged and does not allow starting of a container.

What exactly should I do now, to get privileged as it is being described in the Podman documentation, meaning that ALL security features get deactivated, including AppArmor, so that I can start a container like a few weeks ago with just sudo podman run --privileged hello-world?

[mheon]

What we're talking about here is a case where both flags are specified.

If I call podman run -t -i --privileged --security-opt apparmor=$PATH ... we've been given two flags that are in conflict in what they request (remove all security for the container, but also use the specified apparmor profile). With SELinux (and I believe seccomp) we will honor the privileged flag by removing all security from the container, but then re-add the specific security feature that the user requested.

[alitvak69]

@mheon But the problem is, the error appears even without --security-opt specified. It affects deployment of ceph containers that uses privileged option for example. So something changed in podman 2 vs 1.93

[TomHutter]

I experience the same behavior on Ubuntu 20.04:

podman run --rm -it --privileged --security-opt apparmor=unconfined  debian /bin/bash
Error: invalid config provided: AppArmorProfile and privileged are mutually exclusive options

The podman man page tells me:

apparmor=unconfined : Turn off apparmor confinement for the container

Which was the behavior before on Ubuntu 18.04.

[alitvak69]

I could successfully run this

podman run --privileged --security-opt label=disable hello-world

[TomHutter]

Yes, this works for me also. Thanks @alitvak69 . Seems I got the documentation wrong. Nevertheless podman behaves different in Ubuntu 20.04, or at least 18.04 accepted --security-opt apparmor=unconfined.

[alitvak69]

It is actually confusing, disabling label in config file (label = false) systemwide has no effect. Still I would like to preserve compatibility if possible, and clarify documentation.

[ormandj]

I agree with preserving compatibility, this is a 'breaking' change in behavior. The default behavior shouldn't change drastically enough to break existing software without release notes/documentation updates and time to remediate if necessary.

[rhatdan]

Yes no one is arguing this is not a bug. It is definitely a big bug.

[alitvak69]

I also believe the fix has been merged several days ago.

[rhatdan]

If people with knowledge of AppArmor could take the PR for a spin, It would be appreciated. I think this is correct, but I am too lazy to setup a AppArmor machine to test it out. :^(

[sebastian-philipp]

relates to https://tracker.ceph.com/issues/46429

[alitvak69]

This comment is slightly unrelated to a topic but perhaps it makes sense to have a separate repo on OBS, call it old for example. This repo would contain latest 1.x podman packages. This way people will continue reporting issues with 2.x but can revert their production to 1.x. This is not ideal but may be a work around for now.

[euh2]

I used OBS to build podman v1.9.3 packages. Feel free to use it until a proper solution arrives.

[mheon]

Should be fixed in master now, will be in 2.0.3

[bbros-dev]

For anyone who is constrained in getting the updated version, instead of --privileged, I was able to work around this with the hack:

podman run --cap-add=all....