First of all, there's a certain level of ignorance about the inetd problem demonstrated in this article. inetd does, indeed have a configurable setting that disables a service if it spawns too many times in a short period of time. The reason is simple -- it's better to disable a service than have the whole box brought to its knees by the load. inetd was *never* intended for running critical services, and the startup overhead of launching a new process for each connection alone clues most people in that busy services should be run on their own, not through inetd.

Secondly, if someone has high enough privilages to patch your kernel, they *already* own your system. All that ability does is make it easier for them to cover their tracks. Even if they couldn't alter the kernel, they would already have the ability to do essentially anything they want with the system. I do not see this particular issue as important enough to make a fundamental change like moving over to a Trusted Computing-style platform where "unofficial" binaries are completely locked out. One of the key features of "Trusted Computing" is that only approved, digitally-signed binaries are allowed to run on the system. This seems fundamentally at odds with what open-source computing is all about. What good is having the source code if a binary you compile yourself won't be allowed to run?


[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/191/23177#23177