Package: debspawn Severity: serious Justification: security hole Tags: security
When building a package using debspawn, it dynamically allocates a system user that is used to perform the build. Since system users are allocated sequentially, the chosen uid is very likely to collide with a uid outside the nspawn container. This enables two possible privilege escalations: * If an unprivileged user is entitled to perform builds via debspawn, she gains privileges of the build uid inside the container and this is an expected part of the security model of debspawn. However that same uid is very likely used outside of the container for a different purpose (usually a system daemon). A number of resources are shared between the outer os and the container despite being separated by a pid namespace. For instance, resource limits are shared. It is very likely that a privilege escalation from the build user inside the container to the service user (with same uid) is possible. The culprit here is the accidental sharing of uids for two different purposes. * Likewise, the privilege escalation works in the other direction. The service that shares its uid with the build user can simply kill build processes with any signal or change arbitrary files in the build tree. Again, it is the sharing of a uid that enables this. I basically see two options for fixing this: * The build user is forced to use a uid that is not allocated elsewhere. pbuilder follows this approach and fixes a uid that is not normally allocated. * A user namespace would remap the uid space inside the container to a high, private uid range. While the build uid inside the container would equal a system user outside, the namespace would still separate them. FD: Initial disclosure to Matthias and the security team happened on May 11th. Both agreed to publish the issue. Helmut
