When Good Logs Go Bad: Do You Understand Your Logs?

Published: 2014-05-29. Last Updated: 2014-05-29 14:59:14 UTC
by Johannes Ullrich (Version: 1)

This keeps happening over and over, and we aren't really covering this as much as we should: Readers finally heed our advise and look at their logs! Now this should make us proud and glad. But then the bad thing happens: They have no idea what they are looking at, and the logs look scary. So the conclusion is "I am hacked!". People stop working and their only goal is to get back a clean system which they find impossible to achieve. For some people, this even results in them becoming unemployed, or worse: They become security professionals.

With this introduction, I got a challenge for you: Take a system that you reasonably believe to be "clean". Find some logs that make you think otherwise, and try to explain them. To get started, here some from my iMac desktop that I use to type this diary:

May 29 10:04:37 iMac.local com.apple.authd[57]: Succeeded authorizing right 'com.apple.ServiceManagement.daemons.modify' by client '/usr/libexec/UserEventAgent' [11] for authorization created by '/usr/libexec/UserEventAgent' [11] (12,0)

Even after a full 5 minutes with Google, I am kind of at a loss as to what this means. In my opinion it is nothing to worry about, but then again, that is just my "impression".

May 29 10:46:16 iMac.local sandboxd[253] ([7255]): com.apple.WebKit(7255) deny file-read-data /Library/Preferences/com.apple.security-common.plist

Seems like a coding bug in Safari to me. Why? Well, WebKit is the rendering engine behind Safari, and Safari runs inside a sandbox on OS X. But why does it try to read "com.apple.security-common.plist"? Looks bad. Maybe I am just doing this too long to still care about some of these messages. Sure looks dangerous to someone who still does care.

So what are your favorite non-events? How do you figure out what is a problem and what isn't? Do we need a database of log messages with translations?

And remember,