Users don't always WANT to attack
Posted Feb 1, 2006 16:35 UTC (Wed) by dwheeler
In reply to: VERY interesting - but security implications to others?!?
Parent article: Van Jacobson's network channels
Sure, if a user is malicious, they can boot the system into some OS where they're fully privileged and attack. Or just unplug the network, plug in their own laptop where they have all privileges, and attack.
That's not the point. Not all users are malicious. Sometimes they run programs that APPEAR to do one thing, but do another. Sometimes systems run servers (like web servers) that an attacker can somehow subvert. In THOSE cases, I'd like the system to still limit what the attacker can do, INCLUDING limits on how the attacker can attack other systems.
Sure, all systems should be invulnerable to all attackers. But they aren't. Anyone who's managed a big network knows how hard it is to keep EVERYTHING secure, ESPECIALLY since there are some vendors who do not release patches for KNOWN vulnerabilities (names withheld, but Google can help you find them rather quickly). So you really need defense-in-depth: you need to try to make it so that attackers have to break down MULTIPLE barriers to get the goods.
Limiting the network-level actions of unprivileged accounts is not the be-all of security. But it's one of the few mechanisms we CURRENTLY have deployed widely that slow the spread of attacks across a network. Diseases that spread rapidly are often unstoppable, because you just don't have enough time to react. Slowing the spread of a disease is key to countering it. Similarly, in the network world, slowing down attack vectors is also key to countering it.
I'd like to see that packets from untrusted user apps are still FORCED to obey certain limits on what they can send.
You don't need a system-wide lock to do that kind of checking; after a call to the kernel, the memory could be mapped out and checked WITHOUT harming the cache lines of other systems.
For most systems it'd just involve checking a few bytes... nothing expensive, and certainly taking less time than sending something down any network port.
to post comments)