Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop.
Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
VERY interesting - but security implications to others?!?VERY interesting - but security implications to others?!?Posted Feb 1, 2006 2:20 UTC (Wed) by elanthis (subscriber, #6227)In reply to: VERY interesting - but security implications to others?!? by dwheeler Parent article: Van Jacobson's network channels
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.
(Log in to post comments)
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 (subscriber, #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 im14u2c (subscriber, #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.
|
|||||||||||