On Tue, 2017-12-19 at 12:11 +0100, Samuel Thibault wrote: > Ben Hutchings, on mar. 19 déc. 2017 03:37:03 +0000, wrote: > > On Mon, 2017-12-18 at 01:44 +0100, Samuel Thibault wrote: > > > Ben Hutchings, on lun. 18 déc. 2017 00:37:48 +0000, wrote: > > > > On Mon, 2017-12-18 at 00:12 +0100, Samuel Thibault wrote: > > > > > It can be used as a maintained user-land TCP/IP stack. > > > > > > > > Why would this be useful for Debian systems, which already have a much > > > > better performing TCP/IP stack? > > > > > > But the kernel-provided stack can't be manipulated by userland for > > > e.g. VPNs, ppp, etc. without having to be root. > > > > [...] > > > > Not quite. On Linux you need CAP_NET_ADMIN in some user namespace. > > Which is not so much more available. > > > (In Debian this feature is guarded by a sysctl that's off by default, > > as a security mitigation.) > > And thus is not generally available in installed systems. > > > Even if that's disabled, a privileged container manager can create a > > new user namespace and start a container within that namespace with the > > CAP_NET_ADMIN capability. > > Which doesn't usually happen on installed systems. I won't event try, > I'm sure admins of my work clusters will refuse to enable this, for fear > of the security consequences.
But they would be happy to let you run an alternate TCP/IP stack that is invisible to standard administrative tools? > > To use lwip you would presumably need raw access to a network device, > > which also requires a privileged capability. > > Not if it's a vpn or ppp over USB, etc., precisely. Direct access to USB serial devices is privileged, but you're right that anyone can run a VPN on top of TCP or UDP. > It is exactly the kind of reason why qemu's user-land TCP/IP stack is > the default. But it doesn't work very well (slow, and only forwards TCP and UDP). Ben. -- Ben Hutchings 73.46% of all statistics are made up.
signature.asc
Description: This is a digitally signed message part
