containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.83k stars 2.42k forks source link

App Armor Profile not loading properly using OCI hooks #23589

Closed Manik2708 closed 3 months ago

Manik2708 commented 3 months ago

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
```text
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)
    }
}
  1. Run the container using (change the image name according to you)

    sudo podman run -d nginx
  2. Run

    sudo podman inspect container_id/name | grep -i AppArmorProfile

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

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

  4. Now exec into the container and run

    cat /proc/1/attr/current

    You will observe that it also shows the correct profile name

  5. Now run this inside container

    cat /proc/self/attr/current

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

  6. 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 commented 3 months ago

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

Manik2708 commented 3 months ago

If that is the case, we can!