Am 01.05.19 um 09:56 schrieb L. van Belle:
Hello Louis,
@intrigeri: Could you please give me a hint?
TL;DR: The path to the ntp_signd socket in the current AppArmor profile
for ntp is wrong ( /{,var/}run/samba/ntp_signd/socket rw, but it is now
in /var/lib/samba/ntp_signd ) . I'm trying to reproduce the bug, but I
can see ntp accessing this socket although the (unfixed) AA-policy is
loaded and in enforce mode.
> We got reports on the samba list of this.
> See: https://www.spinics.net/lists/samba/msg156739.html
Thanks for the link. According to that one the only necessary change
would be for the path to the ntp_signd socket, but in this bug you requested
- # samba4 ntp signing socket
- /{,var/}run/samba/ntp_signd/socket rw,
+ # To sign replies to MS-SNTP clients by the smbd daemon /var/lib/samba
+ /var/lib/samba/ntp_signd r,
+ /var/lib/samba/ntp_signd/{,*} rw,
- # samba4 winbindd pipe
- /run/samba/winbindd/pipe rw,
+ # samba4 winbindd pipe
+ /{,var/}run/samba/winbindd r,
+ /{,var/}run/samba/winbindd/pipe rw,
+
+ # samba4 winbindd privileged pipe ?
+ /var/lib/samba/winbindd/ r,
+ /var/lib/samba/winbindd/pipe rw,
Don't get me wrong, I'm sure you understand all this a lot better than I
do, but Debian is in Deep Freeze right now, and I have to run all
changes by the release team for approval. Adding access to the
privileged pipe is new, and even you added a '?' in there.
> And i verified the user his problem and also noticed the wrong path also,
> and reported it as fix with the change.
>
> You said you did follow the wiki, which part?
That one
https://wiki.samba.org/index.php/Time_Synchronisation#With_ntpd
> Is windows in you test case syncing time over AD? Or ntp protocol?
I didn't set anything, so I assume based on
https://wiki.samba.org/index.php/Time_Synchronisation#Default_Time_Source it
would be using NT5DS?
I also tried
https://wiki.samba.org/index.php/Time_Synchronisation#Setting_User_Defined_Time_Sources_and_Options
with the NTP server set to the DC and Type being NT5DS, I don't see a deny.
I see the client sending NTP towards the (only) DC, with a
Network Time Protocol (NTP Version 3, client)
Flags: 0xdb, Leap Indicator: unknown (clock unsynchronized), Version
number: NTP Version 3, Mode: client
11.. .... = Leap Indicator: unknown (clock unsynchronized) (3)
..01 1... = Version number: NTP Version 3 (3)
.... .011 = Mode: client (3)
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0,015625 sec
Root Delay: 0,063690185546875 seconds
Root Dispersion: 8,79443359375 seconds
Reference ID: NULL
Reference Timestamp: May 3, 2019 21:45:14.372999999 UTC
Origin Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Transmit Timestamp: May 3, 2019 21:45:14.372999999 UTC
Key ID: 50040000
Message Authentication Code: 00000000000000000000000000000000
The ntp server responds with some sort of MAC
Network Time Protocol (NTP Version 3, server)
Flags: 0x1c, Leap Indicator: no warning, Version number: NTP Version
3, Mode: server
00.. .... = Leap Indicator: no warning (0)
..01 1... = Version number: NTP Version 3 (3)
.... .100 = Mode: server (4)
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0,000000 sec
Root Delay: 0,032440185546875 seconds
Root Dispersion: 0,00323486328125 seconds
Reference ID: 223.239.245.186
Reference Timestamp: May 3, 2019 21:43:24.502068323 UTC
Origin Timestamp: May 3, 2019 21:45:14.372999999 UTC
Receive Timestamp: May 3, 2019 21:45:14.450592547 UTC
Transmit Timestamp: May 3, 2019 21:45:14.450703072 UTC
Key ID: 50040000
Message Authentication Code: ed6722b3527e89be1a5ff779623b30e2
The client sets the time (I had manually changed it to be 20h off)
correctly upon reception. But I SHOULD definitely be getting a deny
since the path in the AppArmor profile is obviously wrong.
> The PC's get the time always from ad, so that that works is correct,
> but if the time offsets and it needs to correct it, then you should see the
> deny message of apparmor.
I don't, during the whole process my ntpd with the unchanged AppArmor
profile did not log a single deny :-(
I'm utterly confused why. I DO see ntpd
---
root@dc01:~# aa-status
apparmor module is loaded.
8 profiles are loaded.
8 profiles are in enforce mode.
/usr/bin/man
/usr/sbin/named
/usr/sbin/ntpd
/usr/sbin/tcpdump
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode.
/usr/sbin/named (28770)
/usr/sbin/ntpd (31329)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
---
root@dc01:~# grep samba /etc/apparmor.d/usr.sbin.ntpd
# samba4 ntp signing socket
/{,var/}run/samba/ntp_signd/socket rw,
# samba4 winbindd pipe
/run/samba/winbindd/pipe rw,
/etc/apparmor.d/local/usr.sbin.ntpd is empty
still I do see ntpd accessing the socket in strace when the windows box
makes a NTP query
connect(4, {sa_family=AF_UNIX,
sun_path="/var/lib/samba/ntp_signd//socket"}, 110) = 0
That appears to work despite the profile not containing it.
Bernhard
