Description of problem: Users that require audit events typically have this set of rules: -a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k time-change -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change -a always,exit -F arch=b32 -S clock_settime -F a0=0 -k time-change -a always,exit -F arch=b64 -S clock_settime -F a0=0 -k time-change -w /etc/localtime -p wa -k time-change The problem is that by default, the chrony program adjusts time several times a millisecond continuously. type=SYSCALL msg=audit(03/05/2013 05:47:55.745:26) : arch=x86_64 syscall=adjtimex success=yes exit=0 a0=0x7fff47656650 a1=0x0 a2=0x0 a3=0x4000 items=0 ppid=1462 pid=1463 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=time-change ---- type=SYSCALL msg=audit(03/05/2013 05:47:55.745:27) : arch=x86_64 syscall=adjtimex success=yes exit=5 a0=0x7fff47656650 a1=0x0 a2=0x0 a3=0x4000 items=0 ppid=1462 pid=1463 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=time-change ---- type=SYSCALL msg=audit(03/05/2013 05:47:55.745:28) : arch=x86_64 syscall=adjtimex success=yes exit=0 a0=0x7fff47656650 a1=0x0 a2=0x0 a3=0x4000 items=0 ppid=1462 pid=1463 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=time-change ---- type=SYSCALL msg=audit(03/05/2013 05:47:55.745:29) : arch=x86_64 syscall=adjtimex success=yes exit=0 a0=0x7fff47656640 a1=0x7f4de6627550 a2=0x0 a3=0x4000 items=0 ppid=1462 pid=1463 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=time-change ---- type=SYSCALL msg=audit(03/05/2013 05:47:55.745:30) : arch=x86_64 syscall=adjtimex success=yes exit=0 a0=0x7fff47656610 a1=0x7fff47656708 a2=0x7f4de640dc10 a3=0x4000 items=0 ppid=1462 pid=1463 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=time-change This is far too aggressive for casual use. Version-Release number of selected component (if applicable): chrony-1.27-0.5.pre1.git1ca844.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Add the above rules to /etc/audit/audit.rules 2. Let system run 3. ausearch --start today -i --key time-change Additional Information: I think the solution is to provide a default configuration that syncs only occasionally rather than many times a millisecond. Also, I did not install this package by intention. It was pulled in by some dependencies. So, this is not being pulled in because I want my system super accurate.
I suspect most of these are read-only adjtimex calls (modes=0) to obtain the remaining offset correction when reading the clock. Normally, the clock should be modified only about once per 1024 seconds after the synchronization has stabilized. Is it possible to extend the rule to check the modes field in the timex structure passed to the syscall? You can use ntpd from the ntp package instead of chrony, it shouldn't call adjtimex as often as chronyd does.
Its not possible to do anything with the adjtimex syscall because it has one argument and its a pointer to a user space timex struct. The audit system can only check arguments passed by value rather than dereference pointers to the value. The synchronization never seems to settle. My system has been on 2 hours and I have a little over 1900 events. By default, this is too aggressive. As for ntpd, well...this package is required by revisor and anaconda. So, its pulled in and the daemon is enabled by default. This leads to flooding the audit logs. If ntpd does it, I'll open a bz on that package as well. But out of the box, this daemon is too aggressive. For example, looking at how often it does something: 10:39:12.791:1303 10:39:12.791:1304 10:39:12.911:1305 10:39:12.911:1306 10:39:12.911:1307 10:39:12.791:1302 10:40:59.077:1309 10:40:59.077:1310 10:40:59.184:1311 10:40:59.184:1312 10:40:59.184:1313 10:40:59.077:1308 10:43:25.722:1315 10:43:25.722:1316 10:43:25.811:1317 10:43:25.811:1318 10:43:25.811:1319 10:43:25.722:1314 10:47:34.406:1321 10:47:34.406:1322 10:47:34.448:1323 10:47:34.448:1324 10:47:34.448:1325 10:47:34.448:1326 10:47:34.406:1320 10:47:34.448:1327 10:47:34.448:1328 10:47:34.448:1329 10:47:34.448:1330 10:47:34.448:1331 10:47:48.475:1333 10:47:48.475:1334 10:47:48.597:1335 10:47:48.597:1336 10:47:48.597:1337 10:47:48.475:1332 This is hour:minute:second.millisecond:serial number within the millisecond. Its seems to let the system go for a couple minutes or a couple seconds, but then starts all the syscalls again.
Perhaps the audit daemon could be improved to merge identical successive messages? By default there are 4 servers in chrony.conf. The initial polling interval is 64 seconds, which is gradually increased to 1024 seconds. For each server query there are 6 time stamps made (adjtimex calls). One after select() timeouts, two before the packet is send, one for select() when the packet is received, one to correct SO_TIMESTAMP and another in source selection. I think it's working as expected. From that six calls two or three could probably be eliminated/cached, but I'm not sure if that would help you. There shouldn't be any hard dependencies on chronyd in default install as it is supposed to be replaceable with ntp, it might be worth to file some bugs.
The upstream code has now reduced the number of adjtimex calls approximately by half. I think this is best what can we do now. http://git.tuxfamily.org/chrony/chrony.git/?p=chrony/chrony.git;a=commitdiff;h=8aa9eb19c826f3ea4a9c2ce5e3a71b74aeeb99d0;hp=62027f1b47ada22a910d02d7eb953d2e6a45bf84
Thanks. It is a mandatory requirement on government system to audit any change to the clock because that could mess up correlation of logs should an intruder try to make it look like something happened at a different time.
chrony-1.28-0.1.pre1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/chrony-1.28-0.1.pre1.fc19
Package chrony-1.28-0.1.pre1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing chrony-1.28-0.1.pre1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11434/chrony-1.28-0.1.pre1.fc19 then log in and leave karma (feedback).
chrony-1.28-0.1.pre1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
chrony-1.28-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/chrony-1.28-1.fc18
chrony-1.28-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.