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

[John Johansen]

On 5/5/19 3:41 AM, Christian Boltz wrote:
> 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?
> 

yes currently fine grained mediation for sockets atm means anything
beyond the very basic socket mediation that is supported for all socket
families. ie. yes you are allowed access to this socket family.

We do have plans to refine this, currently fine grained implies both
socket based operations (connect, bind, ...) controls, and address
information controls (eg. af unix socket at /tmp/foo) which is
address family specific.

The rework of the socket mediation that is going upstream will allow
us to split this so we can have coarse socket mediation at the
af_family, type as we currently have it AND the protocol, and
operation.

At which point the fine grained mediation of a give address family
will only be about mediating on the additional information an
address family brings. eg. where the socket is located.

but atm socket mediation is limited to
- address family
- type  (stream, dgram, packet, ...)

The af_unix mediation has been bumped from the 5.2 pull request to
5.3 as we ran into so isses and need to rework a bit around LSM
the LSM stacking patches.