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