| |||||||||||||
|
| |||||||||||||
VERY interesting - but security implications to others?!?VERY interesting - but security implications to others?!?Posted Jan 31, 2006 23:27 UTC (Tue) by dwheeler (guest, #1216)Parent article: Van Jacobson's network channels This looks VERY interesting, and I expect that this WILL be implemented. I think this is (mostly) a very good idea. But it appears to me that this has a dark side. Today, because the kernel assembles packets, then only trusted (root) programs can forge packets and create many kinds of funky attack packets. If user-level applications can create arbitrary packets, then ANYONE -- even untrusted applications -- can forge arbitrary packets and arbitrary attack packets. Clearly, in some situations this wouldn't matter. But historically getting only "user privileges" limited what you could do, including having to give away your IP address and only being able to send certain kinds of packets. This gives a new weapon, not so much against the machine IMPLEMENTING the new approach, but against OTHER machines (whether or not they do so). Today, given only low privileges, you can't create funky packets (like Xmas tree ones) or total forgeries. Unless there are kernel-level checks or I misunderstand something, you CAN cause these problems. Just imagine; a user-space app sends out a broadcast from 127.0.0.1, etc., etc. There's a LOT of mischief that's been limited to kernel-space programs before that this might expose. I'd like to see an implementation automatically check the outgoing packets for certain properties as part of the kernel (e.g., valid sender IP and port address, etc.). But I fear that won't happen by default, because (1) that would take extra time, and (2) it only affects OTHER people. And I understand (though don't agree with) the other side of the coin: Yes, of course people who have root can send any packet. That's not my point. My point is that for a large, shared network to be useful, there needs to be a defense-in-depth so that attackers aren't automatically given the whole store when they get just a little privilege. This would kick away one of those mechanisms. Eek.
(Log in to post comments)
VERY interesting - but security implications to others?!? Posted Feb 1, 2006 2:20 UTC (Wed) by elanthis (subscriber, #6227) [Link] That whole "only root can do stuff to the network" reasoning is complete bunk.
Absolutely nothing stops a user from booting their workstation with a LiveCD that they have root access to. Or plugging in a different machine to the network. Or rebooting into single-user mode.
You cannot rely on a per-machine control like root access to protect your network. If you want to do that, you have to have some sort of encryption/signing on every network packet sent and physically lock down the end-user workstations so that they can't reboot into single-user mode or pop in a LiveCD or modify/replace the hard disk.
That's not the only meaning of that statement Posted Feb 1, 2006 2:34 UTC (Wed) by Ross (subscriber, #4065) [Link] I sure hope that no application which I run as a normal user is able to reboot the system into another operating system in order to use raw sockets and low port numbers.
If it could, that's what I'd call a gaping security hole.
protocol validity checks Posted Feb 1, 2006 3:57 UTC (Wed) by xoddam (subscriber, #2322) [Link] can imagine an internal 'firewall' inspecting the header of each packet traversing a channel from userspace to ensure the app has sufficient privilege to send it. A pipeline stage with negligible performance impact -- it wouldn't thrash the cache, and if it's in the kernel it would involve no extra context switches.
protocol validity checks Posted Feb 1, 2006 6:38 UTC (Wed) by cventers (subscriber, #31465) [Link] Yeah, since you're writing into mapped memory, the kernel can check itout in place. And since there's no copy, it's going to be hanging out in the cache when the check has to take place.
protocol validity checks Posted Feb 3, 2006 4:15 UTC (Fri) by zblaxell (subscriber, #26385) [Link] kernel can check it out in place...while the user, maybe on another CPU, switches a few bits just after the kernel check but before the network card picks up the data.
Sneaky indeed! Posted Feb 3, 2006 5:48 UTC (Fri) by xoddam (subscriber, #2322) [Link] Ok, freely mapped memory doesn't cut it then. I wonder what theperformance impact of changing packet buffers' page permissions would be, relative to copying (and relative to keeping the TCP implementation in kernel space)?
That's not the only meaning of that statement Posted Feb 1, 2006 12:15 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] I think parent's point was about a living user doing a cold boot with a live CD, and then comitting mischief, not about an existing application you're running somehow warm booting and doing that.Clearly, unprotected ON/OFF switches and promiscuous BIOS boot settings can be a gaping security hole.
That's not the only meaning of that statement Posted Feb 1, 2006 13:54 UTC (Wed) by Ross (subscriber, #4065) [Link] Yes and my point what is equivalent with physical security is not the totality of the problem. Of course if someone has physical access to your network they can any packets they like on it. But unpriviledged processes running on your server don't have physical access, but in the same scenario they would have the same level of access.
That's not the only meaning of that statement Posted Feb 2, 2006 4:05 UTC (Thu) by elanthis (subscriber, #6227) [Link] And my point remains... what is that unprivileged process going to do that you couldn't do by plugging in a laptop or some other device onto the network?
If you are implicitly trusting every packet sent by some 'trusted' host (which, if it were truly trusted, would never be running any malicious code anyhow), or trusting anything running on port 1024 down, you're not running a very secure network at all.
There is no security at the IP level at all. If you want trust and security, you have to put it all in higher layers.
That's not the only meaning of that statement Posted Feb 2, 2006 5:28 UTC (Thu) by Ross (subscriber, #4065) [Link] If you're only point is that security shouldn't depend on the network not being compromised I agree. However malicious users with unfettered physical access are not at all equivalent to malicious processes running under unpriviledged ids and that anything which makes them equivalent is decreasing security. Does it matter for well designed programs? No. But unfortunately tons of commonly used software is not well designed. If you can't trust IPs, port numbers, etc. many things break down. If you can't trust a program a user downloaded you should worry, but your network is not automatically compromised unless there is something which can be exploited on the system.
Users don't always WANT to attack Posted Feb 1, 2006 16:35 UTC (Wed) by dwheeler (guest, #1216) [Link] 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.
VERY interesting - but security implications to others?!? Posted Feb 1, 2006 20:08 UTC (Wed) by NAR (subscriber, #1313) [Link] Absolutely nothing stops a user from booting their workstation with a LiveCD that they have root access to.Except the fact that this user can be an unauthorized one who've just cracked into the system from an other continent using the latest bug in a PHP BBS and his processes are running as 'nobody' user. He'd have hard time putting a live CD into the computer, but still we really don't want him to send arbitrary packets into the network.
VERY interesting - but security implications to others?!? Posted Feb 8, 2006 13:14 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] I wonder if you can still get most of the benefits of network channels if you limit their accessibility to special user IDs, and then require non-privileged applications to use cooperating threads--one privileged, one not--to send packets.
That way, the TCP/IP implementation can be stored away in a fixed implementation that root checks in on (and the kernel may even checksum at lauch time), but the processing still lives in userspace. It looks a little like the priv-sep that sshd uses.
Granted, with two cooperating threads, you get back to some of the context switching issues, but still it feels a little more flexible than keeping it in kernel space.
VERY interesting - but security implications to others?!? Posted Feb 11, 2006 9:33 UTC (Sat) by efexis (guest, #26355) [Link] If my memory serves me correctly, there are one or two servers out there on the internet that run linux. I know it's not very common, but some of them actually rent space/bandwidth/etc so that people can host their own websites, and they allow these users to run code (cgi scripts) or even have shell access via telnet/ssh.
You obviously don't see this practice taking off, but even so, I think if you told someone who offers shared hosting, not to bother protecting against ways unprivilidged users can cause havock, because somebody "can simple break into the datacenter with a boot CD or laptop"... you'd probably get an incredibly sarcastic response.
But no, you stick to talking about how to improve the performance of a 10Gig heavy loaded network interface --on a workstation-- where it'll really count.
VERY interesting - but security implications to others?!? Posted Feb 2, 2006 4:11 UTC (Thu) by jamesh (subscriber, #1159) [Link] There isn't much problem with this model on the receive end, assuming that the kernel correctly classifies packets and sends them to the right process.
As for sending, all that is necessary is a packet verifier, that makes sure the packet is appropriate for the given socket (which should be a lot simpler than a full TCP send implementation). If the packet shouldn't be getting sent from the socket, the kernel doesn't transmit it.
VERY interesting - but security implications to others?!? Posted Feb 3, 2006 18:57 UTC (Fri) by caitlinbestler (subscriber, #32532) [Link] The same filter rules that route inbound packetscan be used to validate outbound packets. You simply do not accept packets from a channel if the response packet would not be routed to the matching channel.
So the privileged end of the channel can validate
|
|
||||||||||||