On 23/09/15 03:42, Yousong Zhou wrote: > On 23 September 2015 at 01:52, Bastian Bittorf <bitt...@bluebottle.com> wrote: >> dnsmasq maintains dnsmasq.time across reboots and uses it as a means of >> determining if current time is good enough to validate dnssec time >> stamps. By including /etc/dnsmasq.time as a time source for sysfixtime, >> the mechanism was effectively defeated because time was set to the last >> time that dnsmasq considered current even though that time is in >> the past. Since that time is out of date, dns(sec) resolution would >> fail thus defeating any ntp based mechanisms for setting the clock >> correctly. >> >> In theory the process is defeated by any files in /etc that are newer >> than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp >> on process TERM so hopefully /etc/dnsmasq.time is the latest file >> timestamp in /etc as part of openWrt shutdown/reboot. >> I'm glad there's so much interest in this topic. I have to declare a bias/interest in this because I was the guy who persuaded Simon (dnsmasq) to implement the timestamp check file option. The motivation was to provide an easier path for users of dnsmasq to switch on dnssec and have it 'just work', well hopefully. The existing --dnssec-no-timecheck has some practical difficulties and at the time I was marginally involved in the 'tomato' project which just proved too difficult to adapt to use '--dnssec-no-timecheck' > In theory, a security sensitive mechanism's dependence on a > non-reliable timestamp file with access permission nobody:nogroup > makes little sense to me. How about that we do --dnssec-no-timecheck > on dnsmasq startup time and notify it of the system time change from > ntpd hotplug script? If the concern is someone mangling the timestamp file then a relatively easy solution is to create a dnsmasq user/group, have dnsmasq drop to that user rather than nobody, create a directory solely for the timestamp file '/etc/dnsmasq.d' (perm 600) and store the timestamp file there out of everyone else's reach.
Manipulating the timestamp file and system time before dnsmasq start has the following effects as I understand it: 1) system time equal or ahead of timestamp file - dnsmasq considers system time correct (updates timestamp file) and will now check dnssec signature timestamps. If the system time is not actually 'internet time' (within a tolerance of which I'm unclear) and dnsmasq is using 'dnssec-check-unsigned' then ALL dns resolution will fail (everything is considered BOGUS) - arguably a fail safe in that it just stops! This become really problematic when trying to resolve name to ip addresses of ntp servers ;-) Manual workaround, stop dnsmasq, restart sysntpd, wait 10 seconds, start dnsmasq, get on with life :-) 2) system time behind timestamp file - dnsmasq considers system time 'incorrect' and doesn't check dnssec signature timestamps, yet. dns(sec) resolution will work, though timestamps are not checked. The full implications of this I don't understand (at least I'm honest) dnsmasq compares system time and filestamp time for each lookup and when it detects system time > filestamp time starts checking dnssec signature timestamps (see 1) In essence dnsmasq tries to maintain a 'last known good time' timestamp file. Moving that timestamp file out of everyone else's reach is probably a good idea as this removes one source of manipulation. This 'just' leaves the problem of someone effectively manipulating system time at boot via the 'sysfixtime' script. They can only move the time forward and if they go too far from internet time then name resolution will stop (see 1 above) --dnssec-no-timecheck on the other hand assumes time is incorrect and so by default doesn't check signature timestamps. Signature checking is enabled by sending SIGHUP (which does a few other things as well) A problem with this approach is handling dnsmasq re-starts (crashes)/reconfigures. If by default dnsmasq is always started with '--dnssec-no-timecheck' then a process restart will put it back into 'less secure' mode until something notices and sends another SIGHUP. I guess ntpd could be patched to create a flag that says 'time has been set' and the dnsmasq startup process modified to include/exclude '--dnssec-no-timecheck' as required. Care needs to be taken to remove this flag at reboot. > > Another idea would be to delegate timestamp update task to a specific > service program like ntpd or procd and later on system startup we set > system time from the specific file. > >> Either way, including /etc/dnsmasq.time as a time source for sysfixtime >> is not helpful. > Agree. :-) Including it almost guaranteed dnsmasq fell into the trap mentioned in 1) > > yousong >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
