Arch Linux

Description:

When trying to identify the apparmor label of the current process using the genering /proc/self/attr/current attribute file, I always see -EINVAL returned by the kernel. This breaks some older programs which have been linked against libapparmor 2.x. Reading the label through /proc/self/attr/apparmor/current works.

From what I can tell both accesses should work since there's a generic handling in https://elixir.bootlin.com/linux/v5.12.10/source/security/security.c#L1991 and handlers are hooked up through: https://elixir.bootlin.com/linux/v5.12.10/source/fs/proc/base.c#L2807

I don't see the problem on openSUSE Tubmleweed which also sports a recent kernel (5.12.9-1-default) and has AppArmor enabled by default.

AppArmor has been enabled during boot by setting `apparmor=1 security=apparmor` on the kernel command line.

Additional info:
* package version(s)
linux 5.12.10.arch1-1
apparmor 3.0.1-3

* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

This does not work and returns EINVAL:
cat /proc/self/attr/current

This works (as expected):
cat /proc/self/attr/apparmor/current

I've added kernel probes at relevant functions. The non-working access has this trace:

```
cat 18750 [006] 11622.376493: raw_syscalls:sys_exit: NR 221 = 0
cat 18750 [006] 11622.376494: raw_syscalls:sys_enter: NR 9 (0, 22000, 3, 22, ffffffff, 0)
cat 18750 [006] 11622.376504: raw_syscalls:sys_exit: NR 9 = 140089551740928
cat 18750 [006] 11622.376509: raw_syscalls:sys_enter: NR 0 (3, 7f6923f7f000, 20000, 22, 7f6923f7e010, 0)
cat 18750 [006] 11622.376513: probe:proc_pid_attr_read: (ffffffff8a99c9e0)
cat 18750 [006] 11622.376515: probe:security_getprocattr: (ffffffff8a9e5ca0)
### notice -22 == EINVAL
cat 18750 [006] 11622.376517: probe:security_getprocattr__return: (ffffffff8a9e5ca0 <- ffffffff8a99ca49) arg1=-22
cat 18750 [006] 11622.376518: raw_syscalls:sys_exit: NR 0 = -22
cat 18750 [006] 11622.376536: raw_syscalls:sys_enter: NR 1 (2, 7ffea52ec0d0, 5, 7f6923f273e0, 0, 7f6923f274e0)
cat 18750 [006] 11622.376546: raw_syscalls:sys_exit: NR 1 = 5
```

While accessing through /proc/self/attr/apparmor/current has this trace:

```
cat 18514 [012] 11400.957324: raw_syscalls:sys_enter: NR 9 (0, 22000, 3, 22, ffffffff, 0)
cat 18514 [012] 11400.957334: raw_syscalls:sys_exit: NR 9 = 140554148229120
cat 18514 [012] 11400.957339: raw_syscalls:sys_enter: NR 0 (3, 7fd55013c000, 20000, 22, 7fd55013b010, 0)
cat 18514 [012] 11400.957342: probe:proc_pid_attr_read: (ffffffff8a99c9e0)
cat 18514 [012] 11400.957344: probe:security_getprocattr: (ffffffff8a9e5ca0)
cat 18514 [012] 11400.957347: probe:apparmor_getprocattr: (ffffffff8aa3a380)
cat 18514 [012] 11400.957351: probe:apparmor_getprocattr__return: (ffffffff8aa3a380 <- ffffffff8a99ca49) arg1=11
cat 18514 [012] 11400.957353: probe:security_getprocattr__return: (ffffffff8a9e5ca0 <- ffffffff8a99ca49) arg1=0xb
cat 18514 [012] 11400.957357: raw_syscalls:sys_exit: NR 0 = 11
cat 18514 [012] 11400.957358: raw_syscalls:sys_enter: NR 1 (1, 7fd55013c000, b, 22, 7fd55013b010, 0)
cat 18514 [012] 11400.957372: raw_syscalls:sys_exit: NR 1 = 11
cat 18514 [012] 11400.957373: raw_syscalls:sys_enter: NR 0 (3, 7fd55013c000, 20000, 22, 7fd55013b010, 0)
cat 18514 [012] 11400.957375: probe:proc_pid_attr_read: (ffffffff8a99c9e0)
cat 18514 [012] 11400.957376: probe:security_getprocattr: (ffffffff8a9e5ca0)
cat 18514 [012] 11400.957377: probe:apparmor_getprocattr: (ffffffff8aa3a380)
cat 18514 [012] 11400.957379: probe:apparmor_getprocattr__return: (ffffffff8aa3a380 <- ffffffff8a99ca49) arg1=11
cat 18514 [012] 11400.957380: probe:security_getprocattr__return: (ffffffff8a9e5ca0 <- ffffffff8a99ca49) arg1=0xb
cat 18514 [012] 11400.957381: raw_syscalls:sys_exit: NR 0 = 0
cat 18514 [012] 11400.957383: raw_syscalls:sys_enter: NR 11 (7fd55013b000, 22000, 0, 22, 7fd55013b000, 0)
cat 18514 [012] 11400.957392: raw_syscalls:sys_exit: NR 11 = 0
```

Tracing access to /proc/self/attr/current on openSUSE with identically configured probes displays the correct behavior in both scenarios.