What I'm considering is not a complex daemon/service that create the container but just create veth pair.
Unc proof of concept uses two separated binaries unc that creates container and unet which is the setuid that configure it's network https://github.com/LK4D4/unc?files=1 Do you think splitting it into two binaries is better security or not? And how is running setuid unet "configure my network please my privileged parnter" is different from calling a service via dbus or socket doing the same thing (from security point of view) On Fri, May 6, 2016, 11:05 PM Daniel J Walsh <dwa...@redhat.com> wrote: > > > On 05/06/2016 03:46 PM, Muayyad AlSadi wrote: > > long long ago we had this < > > https://fedoraproject.org/wiki/Features/RemoveSETUID > > > Yes I remember the guy that did that... The idea there was to take > advantage of File System Capabilities. I believe bubblewrap is > currently using > them although it needs SYS_ADMIN so that feature does not greatly > increase security for bubblewrap. > > > There is probably a good case to be made that setuid is more > > security then a random service that can setup > > > > I totally agree, but my humble (maybe ignorant and less informed) idea > > is something like pam_oddjob_mkhomedir > > it's a process (protected by policy kit) which has a small humble job, > > which is to configure network (ex. add veth pair to some bridge and > > the given user container) > > > In some cases a client server relationship is better then Setuid, but I > believe in this case you would have a hard time doing something clean > and testable by security reasearchers as bubblewrap. >
