On Sunday, June 09, 2013 05:56:42 AM Matthew Garrett wrote: > On Sat, Jun 08, 2013 at 08:28:48PM -0400, Doug Ledford wrote: > > On 06/08/2013 02:35 PM, Adam Williamson wrote: > > > Well, you're defining something as 'bad behaviour' fairly arbitrarily - > > > or at least controversially: not everyone agrees with your definition. > > > > Speaking as a former sysadmin responsible for intrusion detection, this > > is not a controversial definition at all (namely that anything that > > creates audit events without a reasonably just cause is 'bad behavior'). > > It is the only sane definition of 'bad behavior'. Anything that makes > > an admin go chasing ghosts for no good reason is most definitely 'bad > > behavior', and every single audit event on a system must be identifiable > > by the admins before you know your system is secure.
Thanks Doug. I don't think I could have said it better myself. These events also consume space. Each one of these occupy about 600 bytes. But when you multiply that by the number I gave you yesterday for a week of these events, it gets large. Because I work on the audit system, I have a 100Mb dedicated partition for audit logs. Until recently, that would hold about a year's worth of events. The audit rules have not changed in maybe 4 years. When I run aureport --log today, my logs only go back to May 30 of this year. That's how big of an impact this is. As to the reason why I didn't bring this up earlier, upstream broke the audit system on the 3.7 kernel and it wasn't fixed until the 3.9.4 kernel. > I don't think anyone wants these accesses to generate audit records. The > question is whether the right way to fix that is to avoid those accesses > in the first place or to provide a mechanism so that legitimate accesses > don't generate audit records. There isn't a mechanism to allow these to slip through. Over the years I have come to realize that the audit system can be a great resource for debugging user space. It was sitting through one of Dave Jones' why userspace sucks lectures and afterwards pouring through audit logs that I saw that we can find some of these problems. If part of the goals when writing software is correctness and efficiency, then wouldn't failing syscalls be of interest? Not just in the case of EPERM, but also for example EINVAL? Why would anyone write software that is incorrect enough the OS spits it back as EINVAL? I think its because they didn't know and in some cases it was written on another OS that accepts that particular input. To that point, you can load these two rules: auditctl -a exit,never -F arch=b64 -S rt_sigreturn auditctl -a exit,always -S all -F exit=-EINVAL -k einval-test and then use the computer for a while. To see what you get: # ausearch --start today -k einval -m SYSCALL --raw | aureport -x --summary Executable Summary Report ================================= total file ================================= 165 /usr/libexec/mysqld 149 /usr/bin/man 105 /usr/lib/udisks2/udisksd 74 /usr/sbin/libvirtd 16 /usr/lib/systemd/systemd-udevd 8 /usr/lib64/firefox/firefox 5 /usr/bin/python2.7 2 /usr/sbin/modem-manager 2 /usr/sbin/NetworkManager 2 /usr/bin/gnome-terminal 1 /usr/bin/qemu-kvm 1 /usr/bin/knotify4 1 /usr/bin/xchat Who knew all these programs were making invalid syscalls? Which syscalls are we having a problem with? # ausearch --start today -k einval -m SYSCALL --raw | aureport -i --syscall -- summary Syscall Summary Report ========================== total syscall ========================== 320 readlink 149 munmap 74 rt_sigaction 9 ioctl I'll leave it here for anyone curious enough to dig out the details of how each syscall is wrong. But its my belief that these are not intentionally written to fail and people didn't know they were issuing syscalls that will never work. The audit system can be used to find software problems so the system operates more efficiently. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
