Bug#884641: ITP: lwip -- small implementation of the TCP/IP protocol suite
Ben Hutchings, on mar. 19 déc. 2017 22:11:16 +0000, wrote:
> 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:
> > > 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?
Yes, because that stack will only be able to tinker with whatever
resource is used to push packets (vpn, serial port, etc.)
> > > 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,
An admin can be fine with giving access to /dev/ttyUSB0. Giving
namespace capabilities is much more involved.
> > 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).
Which is not an argument, on the contrary :)
Ideally qemu would precisely use lwip to avoid continuing to have to
maintain its own stack.
Samuel
Reply to: