[pkg-apparmor] Help with anope profile and popen()

[intrigeri]

Hi,

Dominic Hargreaves (2025-03-24):
> I've been looking at the long overdue bug:
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036857>
>
> anope uses popen() to execute /usr/sbin/sendmail, so my understanding is
> that the anope profile would need to be able to execute /bin/sh ->
> /usr/bin/dash. So to experiment I added:
>
>   # we need to popen to send email
>   /usr/bin/dash ix,
>
> to the profile
>
> To my surprise, this worked! Why surprised? Because my expectation is that
> given the "ix", the shell would have been forbidden from executing
> /usr/sbin/sendmail (the full existing profile being:
> <https://salsa.debian.org/dom/anope/-/blob/master/debian/apparmor/usr.sbin.anope?ref_type=heads>).
>
> Tests were done from within an up to date sid chroot with the just-uploaded
> anope (but reproducing the issue requires setting up a working IRC server
> and services setup, which is not trivial).
>
> Questions:
>
> 1) why can sendmail be executed in this example?

I don't know. I'm as surprised as you are. If you don't get answers
here, you can reach out to the AppArmor community upstream (#apparmor
on OFTC or apparmor at lists.ubuntu.com).

> 2) what would be the proper solution for this sort of requirement, given
>    that both /bin/sh and /usr/sbin/sendmail are symlinks that can point to 
>    multiple symlinks and apparmor dereferences symlinks before applying
>    the profile?

I don't think we have a super elegant solution handy. We'll have to
enumerate the valid options explicitly. (Which can be generated in
a semi-automated way I suppose, but still.)

I see other profiles assume sh → dash or bash.
Ideally this would be moved to a new abstraction.

Similarly for sendmail, ideally it would be in an abstraction.

> 3) is it generally acceptable to execute a shell inheriting a restrictive
>    profile? On the face of it I think it should be?

Yes, I think it's a common pattern.

Cheers,
-- 
intrigeri