CLONE_NEWUSER trickery: CVE-2013-1858

Recent kernels (3.8+ something) introduced a feature called
user-namespaces (user-ns, CLONE_NEWUSER flag)
in which you can have your own UID 0.
Think of it as a container solution, so you can
set up compartments on a host. A nice thing,
but it has some security implications. In particular
if you mix this feature with CLONE_FS, which means
that the file-system state is shared between the
containers (e.g. processes). You suddenly get this:

The problem here is that parent and child share the
FS info (the chroot in this case), but only the child
has got its own user-ns. Since it has the
capability to do the chroot() in its own user-ns,
it will succeed doing the chroot() syscall but due to
CLONE_FS, it will also affect the parent.
Parent however stays in the init user-ns (the user-ns
that is default upon boot and the namespace where you
want to have root).
Getting a rootshell from inside a user controlled chroot
with help from outside processes is straight forward.

The xSports can be found here.

Update:
A CVE has been assigned (CVE-2013-1858) and a patch was made.

c25k problem solved

Although the c10k problem is not really a problem in
Computer Science anymore, I successfully solved the
c25k problem (and I am not talking about exploit prices)
for myself.

lophttpd can handle even more connections on a commodity PC,
single core, without connection drops. If your network equipment 
is just good enough (GBit patch cable!:)

I added a new -s switch that lets you experiment with different
scheduling strategies if the TCP send buffers start to fill.
Nevertheless, as poll() will not report a POLLOUT revent
if the TCP send buffer is full, the none stragegy should just be fine. 
Other strategies are minimize (reduce chunksize to minimum)
or suspend (temporarily remove client from POLLOUT list, if
TCP send buffer has data from last send). In particular the
suspend strategy may be of interest, as it reduces the
amount of poll events that the kernel needs to check for.
However, I could not measure any real benefit. Probably one
reason more to say that c10k is not a problem anymore since
quite a lot of time.

Interestingly: lophttpd, if under load, can even utilize
more than 100% CPU: