apparmor_secid_to_secctx doesn't allocate memory for secctx on nullptr

Not saying this isn't a bug. But I need more info, something is off. Looking at this apparmor is allocating memory and putting the label into it.

AppArmor nor selinux are allocating a buffer when
char **secdata is null because there is no place to return the value.

When
*secdata is NULL both apparmor and selinux are allocating and returning a value

both apparmor and selinux are overwriting any existing pointer value at *secdata though apparmor may not be zeroing it in an earlier error case.

Simon, any update on this?

Do we know if this is failing on aa_secid_to_label() and if so what is the secid that it is trying to lookup or whether it is aa_label_asxprint() failing to allocate?

I have this on my list for later today to look into.

I've tracked this a bit further. In https://github.com/torvalds/linux/blob/master/drivers/android/binder.c#L3116 security_task_getsecid gives a secid of 0 for the current process which then leads to security_secid_to_secctx returning an error (-95 = EOPNOTSUPP) which indicates it's not even running into https://elixir.bootlin.com/linux/latest/source/security/apparmor/secid.c#L130.

As we see EOPNOTSUPP we run more into https://elixir.bootlin.com/linux/latest/source/security/security.c#L1877 which returns EOPNOTSUPP when the hook isn't implemented. At the moment this doesn't make much sense to me as the LXC container clearly has an AppArmor profile attached.

Sorry this just occurred to me, what kernel are we looking at?

The Ubuntu kernels currently revert apparmor secid support, in favor of a simpler LSM stacking patchset (basically LSM stacking of secids was buggy). This means that the in disco and eoan kernels apparmor does not implement the secid_to_secctx() hook,

Ah that would then actually makes sense. The issue appears on the 18.04 5.0
HWE kernel which is coming from disco. If secid_to_secctx is disabled then
what we see is correct. We might then need to workaround this in the HWE
kernel within the binder driver.

Is there a way we can detect which LSM us currently enabled?

John Johansen <email address hidden> schrieb am Mi., 2. Okt. 2019,
20:25:

> Sorry this just occurred to me, what kernel are we looking at?
>
> The Ubuntu kernels currently revert apparmor secid support, in favor of
> a simpler LSM stacking patchset (basically LSM stacking of secids was
> buggy). This means that the in disco and eoan kernels apparmor does not
> implement the secid_to_secctx() hook,
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1844780
>
> Title:
> apparmor_secid_to_secctx doesn't allocate memory for secctx on nullptr
>
> Status in AppArmor:
> New
>
> Bug description:
> apparmor_secid_to_secctx
> (
> https://elixir.bootlin.com/linux/v5.0.21/source/security/apparmor/secid.c#L75
> )
> only returns the length of the generated secctx string whereas SELinux
> generates a new string
> (
> https://elixir.bootlin.com/linux/v5.0.21/source/security/selinux/ss/services.c#L1282
> )
> when a null pointer is passed for the target security context.
>
> This causes the Android binder driver to fail transactions initiated
> from user space when the kernel is running with AppArmor instead of
> SELinux as no security context was retrieved when calling
> security_secid_to_secctx.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/apparmor/+bug/1844780/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=apparmor; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: jjohansen morphis
> Launchpad-Bug-Reporter: Simon Fels (morphis)
> Launchpad-Bug-Modifier: John Johansen (jjohansen)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: morphis
>

okay I have updated the disco kernel to a v2 of the patch (+v2lp1844186)

sorry wrong bug, comments #7-9 for bug 1844186

from userspace /sys/kernel/security/lsm will provide a list of the active lsms

jj@flux:~$ cat /sys/kernel/security/lsm
capability,yama,apparmorjj@flux:~$

from the kernel you can grab the same info from

char *lsm_names;

in security/security.c

or you can probably just look to see if any hooks are registered on secid_to_secctx by looking at the first entry. Just steal the code from call_int_hook in security/security.c