[pkg-apparmor] Help needed understanding ntp AppArmor profile missing AF_UNIX deny

[Christian Boltz]

Hello,

Am Samstag, 4. Mai 2019, 22:00:23 CEST schrieb Bernhard Schmidt:
> I'm the co-maintainer for the time-sync daemon ntpd, which ships an
> AppArmor profile. We recently received a bugreport about the path
> being wrong for a specific seldomly used feature of ntpd (using a
> socket provided by Samba to sign ntp responses for Samba AD clients)
> being broken with AppArmor, because the path of said socket has been
> changed.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928168

The proposed additions don't look too correct ;-) - see my comment in 
the bugreport.

> The new AF_UNIX socket filename is /var/lib/samba/ntp_signd/socket,
> but the AppArmor profile only allows
> /{,var/}run/samba/ntp_signd/socket, see
> 
> https://sources.debian.org/src/ntp/1:4.2.8p12+dfsg-4/debian/apparmor-p
> rofile/
> 
> usually when something like this happens I'm trying to reproduce it.
> However, in that case I failed. Configuring ntpd for signing did not
> produce any AppArmor denials.
> 
> The system I'm looking at is a plain Buster qemu VM, current kernel
> 4.19.28-2. AppArmor is enabled and working (I used the same system to
> debug/fix some bind9 issues with the profile, also together with Samba
> AD). The profile for usr.sbin.ntpd is loaded and in enforce mode.
> There is no additional configuration in /etc/apparmor.d/local.
> 
> I was looking for quite some time for a local misconfiguration of the
> signing feature, since I had not used it before and wasn't even aware
> of it. But I'm reasonably sure now I have configured it correctly,
> and running ntpd with strace shows it connecting (successfully) to
> the AF_UNIX socket that should be denied by the outdated AppArmor
> policy.
> 
> root at dc01:/etc/apparmor.d# strace -F ntpd -n 2>&1 | grep samba
> [pid   488] connect(4, {sa_family=AF_UNIX,
> sun_path="/var/lib/samba/ntp_signd/socket"}, 110) = 0
> 
> Even more confusing, the original report on the samba mailinglist that
> triggered the bugreport
> 
> https://www.spinics.net/lists/samba/msg156739.html
> 
> says that on Ubuntu 18.04 there is an AppArmor denial for this
> configuration, which is fixed by changing the path in the profile.
> 
> I have no concern changing the obviously outdated path in the profile,
> but I'd love to understand why AA is not flagging a DENY here.

Ubuntu has some AppArmor kernel patches that are not upstream yet. 
In these cases, the upstream kernel doesn't deny the affected event 
(actually it doesn't even mediate it) while the Ubuntu kernel mediates 
and possibly denies it.

AF_UNIX might be the key here - 
https://gitlab.com/apparmor/apparmor/wikis/Kernel_Feature_Matrix
says that "fine grained af_unix mediation" is wip for kernel 5.2, but 
I'm not sure if that includes connecting to a socket.

John, can you please answer that?


Regards,

Christian Boltz
-- 
We are still waiting / working on systemd 222. Staging:A grew to a small
monster that does not want to be tamed... but I'm sure the monster is
getting tired soon. [Dominique Leuenberger in opensuse-factory]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-apparmor-team/attachments/20190505/97550ad2/attachment.sig>