Messages in this thread | | | Date | Thu, 29 Jan 2009 00:28:29 +1100 | From | Bron Gondwana <> | Subject | Re: [PATCH 1/3] epoll: increase default max_user_instances to 1024 |
| |
On Wed, Jan 28, 2009 at 11:36:40AM +0000, Alan Cox wrote: > > > "A kernel upgrade in a -stable series point release fixed a security DoS" > > > > Alan, that's a complete load of bollocks. It broke common configurations > > of java, postfix and apache on real-world machines, causing significant > > actual denials of service in previously reliable configurations. > > It fixed a security DoS. I was merely pointing out that the description > provided before was bogus, incomplete and loaded.
Not allowing user logins would have fixed that particular security DoS too. There's a range of pretty destructive things that can "fix" one issue at the expense of creating others.
This particular choice of fix just happens to have caused at least three reported (though not to LKML, but I'll post the URLs for the other two again in a sec) commonly used applications issues. These applications were using the published API in a way which used to work perfectly well, and not DoSing the system.
How would you define a regression otherwise? A public and commonly used API had a new user-space visable error code added that it had never returned before, and a low enough limit set that this error was seen in practice by multiple sites.
http://marc.info/?l=fedora-devel-list&m=123134150926934&w=2
http://pero.blogs.aprilmayjune.org/2009/01/22/hadoop-and-linux-kernel-2627-epoll-limits/
> > viable within the code. The DoS works by creating epoll descriptors > > watching other epoll descriptors, which strikes me as a much less > > real-world actual use pattern than a bunch of separate daemons with an > > epoll watcher each. > > Deliberate attackers don't have to follow typical usage patterns.
Sure, but if typical usage patterns hit your sensor, then you have false positives. Adding a DoS sensor that gets false positives is a regression, and whitewashing it as "fixed a security DoS" is bogus. It did that, but also more than that, and the more was/is sucky.
> > If it's possible to count watches only if they're added to another epoll > > instance, then we'd have a metric that still catches the N^2 attack, but > > doesn't interact with the common non-attacky use-case. > > Agreed entirely.
Yeah, enough arguing hey. Let's come up with a real fix that doesn't give sites the ugly choice between remaining vulnerable to a known DoS attack or hobbling common programs that aren't actually using that many resources.
Bron.
| |