[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Introducing bubblewrap



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 <dwalsh 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]