Bad file access on the rise

[Steve Grubb]

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