| |||||||||||||
VERY interesting - but security implications to others?!?VERY interesting - but security implications to others?!?Posted Feb 1, 2006 20:08 UTC (Wed) by NAR (subscriber, #1313)In reply to: VERY interesting - but security implications to others?!? by elanthis Parent article: Van Jacobson's network channels 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.
(Log in to post comments)
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.
|
|||||||||||||