Known-exploit detection for the kernel

There are a whole lot more tools available to do the alerting based on syslog message than there are going to be if you invent a new protocol.

> If someone is script kiddying their way through a series of exploits to see what sticks, I want the userspace daemon to be able to log them out and ban their IP (and possibly lock their account) *now*, this microsecond, before they get a chance to try the next one. Yes, that does imply potential scheduling hackery to get the data out the exploit alert pipe to the userspace daemon before control is allowed to return to the offending process.

This requires much more significant changes, and really is going to require that you put your response code into the kernel inside the detection routine.

> In theory you'd only get flooded with alerts if the system was flooded with exploit attempts. You'd probably want to know if that was happening, but rate limiting could be done in the userspace daemon.

given that the effort involved in generating the log compared to the action that triggers the log, not having this be rate limited would result in a very good DOS vector.

> Feeding the userspace daemon through syslog is kind of silly; a dedicated pipe the daemon could connect to would be better. Avoiding syslog as a transport means:

> - being able to specify a consistent communication protocol

why can't you use a consistent protocol in your syslog message?

> - possibly being able to avoid parsing entirely, but at the least the protocol can be designed to make the parsing trivial

you can make the parsing trivial in syslog as well

> - not needing to worry about some other syslog output source being tricked into spoofing valid-looking but manufactured exploit logs

you can do this inside syslog with filters today (only send to this output if the source is the kernel and the message contains blah)

> - the daemon being able to sleep on data availability in the pipe rather than having to constantly chew on syslog and spit out the (1 - epsilon) it doesn't need, so the daemon will mostly just be asleep until its needed

again, with filtering in syslog, your userspace daemon can do this today.

And as I noted up at the top, there are a lot more alerting engines around that understand syslog than ones that will understand your new protocol.

Any significant company is already going to have an alerting tool in place, it's far better to integrate with that than to require a new tool be written.