On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp <[email protected]> wrote: >On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer ><[email protected]> wrote: >> On 20 May 2015 at 17:20, Laszlo Papp <[email protected]> wrote: >>> On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer >>> <[email protected]> wrote: >>>> On 20 May 2015 at 17:09, Laszlo Papp <[email protected]> wrote: >>>>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross ><[email protected]> wrote: >>>>>> >>>>>> On 20 May 2015 at 16:02, Laszlo Papp <[email protected]> wrote: >>>>>>> >>>>>>> On a second thought: is even worse now than that, our code has >to >>>>>>> handle _three_ different scenarios: >>>>>>> >>>>>>> 1) Desktop. >>>>>>> 2) Embedded without Yocto or embedded with old Yocto. >>>>>>> 3) Embedded with new Yocto. >>>>>>> >>>>>>> I do not get excited about this. >>>>>> >>>>>> >>>>>> Do as the documentation says in your distro and you have one >scenario. >>>>> >>>>> That means compromising security. I am now looking for the ideal >case >>>>> in the future. What is wrong about dropping the privileges in >busybox >>>>> for undedicated processes without creating this separation? >>>>> >>>>> That would combine the convenience with security, wouldn't it? >>>> >>>> We already do that. Since June 2002. version 0.60.4 >>> >>> Then I cannot understand the incompatible change. If the privilege >is >>> dropped early and the code is well-understood, then what exactly was >>> being solved in here for the price of incompatibility and more >complex >>> environments across projects? >>> >>> But in any case, if BUSYBOX_SPLIT_SUID=0 helps me with being >>> compatible while it still drops the privileges properly as intended >by >>> busybox upstream, I guess I can go for that. I am yet to understand >>> the "certain users do not follow it" part. What exactly? >> >> Certain users don't want to risk bugs in the code before privs are >dropped. >> The only way to make them happy is to split the binary into two, a >suid >> one a a nosuid one. > >OK, well, in that case, the question is: why is it not led by busybox >upstream? Currently, busybox downstream projects can call this >anything. At least, some standard way would be nice, wouldn't it?
The logic where to split is upstream to attempt to have a stable, maintained interface at least. I do not want 2 binaries myself. If there is an attack-vector in the part before dropping privileges then I want to have it fixed. You can ask Denys if he wants to do the 2 binary nonsense upstream, but I will not commit such a thing, fwiw. Cheers, -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
