Valdis.Kletnieksat_private wrote: >The interesting thing about affinity is that it's a case where a rogue >program can "fly under the wire" of all the usual existing tools and *still* >cause a DoS, *and* that there's a demonstrable way to 100% close *that* >set of holes with a kook. I've never understood the LKML's attitude of "don't >even bother because there's other classes of holes" - under THAT logic, the >kernel shouldn't even have the current per-user process limit, since there's >still other ways to hose the system... > > What makes the LKML position reasonable is "threat model." For any security enhancement proposal, one needs to construct a threat model in which the feature will prevent some class of attackers from doing some class of bad things. A security feature that is completely bypassable needs to either be matched up with additional features to close the bypass(es), or the proposal should be dropped. Otherwise you have built a fence half-way around your target. So the affinity hooks will be of use only if you can demonstrate to LKML's satisfaction that all other ways of DoS'ing a local CPU are also closed. That "local" provision is important, for 2 reasons: * The threat model the affinity hook defends against requires that you already have a local process. * Defending against remote DoS is well nigh impossible: someone *always* has a bigger network pipe than you do. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Mon Oct 07 2002 - 17:03:00 PDT