App Armor Profile not loading properly using OCI hooks

[Manik2708]

Issue Description

I am trying to load an AppArmor profile using OCI hooks and without passing the --security-opt flag. But it is causing some issues.

Steps to reproduce the issue

Steps to reproduce the issue

1. Create this kind of hook:

{
 "version": "1.0.0",
 "hook": {
"path": "/path/to/the/script/mentioned/in-2nd-point"
 },
 "when": {
     "always": true
 },
 "stages": ["precreate"]
}

2. Create and compile this kind of script and change the path in above hook (change the appArmorProfile to an already loaded profile

const (
	appArmorProfile = "profile-name"
)

func main() {
	// Read data from stdin.
	data, err := io.ReadAll(os.Stdin)
	if err != nil {
		fmt.Println("Error reading from stdin:", err)
		os.Exit(1)
	}
    var spec specs.Spec


	err = json.Unmarshal(data, &spec)
	spec.Process.ApparmorProfile = appArmorProfile
	if err != nil {
		fmt.Println("Error unmarshaling data to JSON:", err)
		os.Exit(1)
	}

	if err := json.NewEncoder(os.Stdout).Encode(spec); err != nil {
		fmt.Println("Error encoding data to JSON:", err)
		os.Exit(1)
	}
}

3. Run the container using (change the image name according to you)

sudo podman run -d nginx

4. Run

sudo podman inspect container_id/name | grep -i AppArmorProfile

You will see it will show your custom app-armor profile name

5. Now exec into your container and try to violate the profile, you will find that it is not blocking anything

6. Now exec into the container and run

cat /proc/1/attr/current

You will observe that it also shows the correct profile name

7. Now run this inside container

cat /proc/self/attr/current

You will observe it is showing the default app-armor profile not the custom

8. Try out with other PIDs also, you will observe that profile name is not consistent.

Describe the results you received

Results are stated above

Describe the results you expected

I have written the expectations in the description itself

podman info output

host:
  arch: amd64
  buildahVersion: 1.28.2
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.6+ds1-1_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: unknown'
  cpuUtilization:
    idlePercent: 81.52
    systemPercent: 5.75
    userPercent: 12.73
  cpus: 4
  distribution:
    codename: mantic
    distribution: ubuntu
    version: "23.10"
  eventLogger: journald
  hostname: manik
  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
  kernel: 6.5.0-44-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 171126784
  memTotal: 8075739136
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun_1.8.5-1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.5
      commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.0-1_amd64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 1275117568
  swapTotal: 4294963200
  uptime: 10h 13m 10.00s (Approximately 0.42 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/manik/.config/containers/storage.conf
  containerStore:
    number: 10
    paused: 0
    running: 0
    stopped: 10
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/manik/.local/share/containers/storage
  graphRootAllocated: 489997189120
  graphRootUsed: 201084047360
  graphStatus: {}
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /run/user/1000/containers
  volumePath: /home/manik/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 0
  BuiltTime: Thu Jan  1 05:30:00 1970
  GitCommit: ""
  GoVersion: go1.21.1
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.1

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[rhatdan]

I don't see that this is an upstream issue, should I move this to a discussion?

[Manik2708]

If that is the case, we can!

[Luap99]

Now run this inside container

How do you run this? podman exec? This would spawn a new process tree basically and not use your hook to overwrite the profile as that one is only execute for the container creation.

If /proc/1/attr/current shows the right profile then I would assume something like podman run -it $IMAGE sh and then running your tests there will show the profile is active.

---

Second do you actually need a hook you can set --security-opt apparmor=<profile name> I don't have a apparmor system so I haven't checked if that is applied correctly to podman exec in this case. IF not that would certainly be a bug.