busybox: passwd: applet not found

busybox: passwd: applet not found

[Laszlo Papp]

Hi,

I am a bit confused why busybox passwd does not work with daisy. It
used to work with dylan. When I try to use "busybox passwd", I am
getting the following output:

    passwd: applet not found

Is something wrong with the busybox maintainer script or somewhere
else? For instance, "busybox pwd" can be located as well as some other
applets that I have quickly run.

Apparently, this does not seem to be in the migration guide either, so
I presume that I am doing something wrong, but what exactly?

Fwiw, "busybox passwd" works just fine on my desktop, too, as expected.

As for completeness, "passwd" does work (without the busybox prefix),
but that is not what I am aiming for. I am always trying to be
explicit because I always want to use busybox's applet, no matter
what.

So what can I do to overcome this?

Ys, L.

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

On 20 May 2015 at 13:55, Laszlo Papp <lpapp@kde.org> wrote:
> Hi,
>
> I am a bit confused why busybox passwd does not work with daisy. It
> used to work with dylan. When I try to use "busybox passwd", I am
> getting the following output:
>
>     passwd: applet not found

is the password applet built?
Check your busybox .config.
Is passwd listed when you invoke plain busybox and have the help-text
printing turned on?

Sometimes code around bsearch is miscompiled but this should not be
the case for your setup, i suppose.

thanks,
>
> Is something wrong with the busybox maintainer script or somewhere
> else? For instance, "busybox pwd" can be located as well as some other
> applets that I have quickly run.
>
> Apparently, this does not seem to be in the migration guide either, so
> I presume that I am doing something wrong, but what exactly?
>
> Fwiw, "busybox passwd" works just fine on my desktop, too, as expected.
>
> As for completeness, "passwd" does work (without the busybox prefix),
> but that is not what I am aiming for. I am always trying to be
> explicit because I always want to use busybox's applet, no matter
> what.
>
> So what can I do to overcome this?
>
> Ys, L.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

On 20 May 2015 at 15:48, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> On 20 May 2015 at 13:55, Laszlo Papp <lpapp@kde.org> wrote:
>> Hi,
>>
>> I am a bit confused why busybox passwd does not work with daisy. It
>> used to work with dylan. When I try to use "busybox passwd", I am
>> getting the following output:
>>
>>     passwd: applet not found
>
> is the password applet built?
> Check your busybox .config.
> Is passwd listed when you invoke plain busybox and have the help-text
> printing turned on?
>
> Sometimes code around bsearch is miscompiled but this should not be
> the case for your setup, i suppose.

ah, the great suid / nosuid split ?
try /bin/busybox.suid passwd instead, the default /bin/busybox
supposedly points to the .nosuid binary.

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 3:05 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On 20 May 2015 at 15:48, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
>> On 20 May 2015 at 13:55, Laszlo Papp <lpapp@kde.org> wrote:
>>> Hi,
>>>
>>> I am a bit confused why busybox passwd does not work with daisy. It
>>> used to work with dylan. When I try to use "busybox passwd", I am
>>> getting the following output:
>>>
>>>     passwd: applet not found
>>
>> is the password applet built?
>> Check your busybox .config.
>> Is passwd listed when you invoke plain busybox and have the help-text
>> printing turned on?
>>
>> Sometimes code around bsearch is miscompiled but this should not be
>> the case for your setup, i suppose.
>
> ah, the great suid / nosuid split ?
> try /bin/busybox.suid passwd instead, the default /bin/busybox
> supposedly points to the .nosuid binary.

Now that just breaks all the code that our software is using. Why did
this binary incompatible change sneak in, and especially: why without
any note in the migration guide? Furthermore, is there a way to
reverse this? I really would like to avoid rewriting my code just
because some other people think it is a cool change. Or is this change
absolutely necessary?

Re: busybox: passwd: applet not found

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On 20 May 2015 at 15:42, Laszlo Papp <lpapp@kde.org> wrote:

> Now that just breaks all the code that our software is using. Why did
> this binary incompatible change sneak in, and especially: why without
> any note in the migration guide? Furthermore, is there a way to
> reverse this? I really would like to avoid rewriting my code just
> because some other people think it is a cool change. Or is this change
> absolutely necessary?
>

The point was to not give "normal" applets such as cat suid rights.  Why
can't your scripts just call passwd directly instead of proxying through
busybox?

Ross

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 3:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 20 May 2015 at 15:42, Laszlo Papp <lpapp@kde.org> wrote:
>>
>> Now that just breaks all the code that our software is using. Why did
>> this binary incompatible change sneak in, and especially: why without
>> any note in the migration guide? Furthermore, is there a way to
>> reverse this? I really would like to avoid rewriting my code just
>> because some other people think it is a cool change. Or is this change
>> absolutely necessary?
>
>
> The point was to not give "normal" applets such as cat suid rights.  Why
> can't your scripts just call passwd directly instead of proxying through
> busybox?

If busybox is available on desktop, I would like to call the busybox
applet through 'busybox appletname'. If I just call passwd, I will
call the desktop version. That is not what I want and this is not how
it has so far worked. I think this feature should have been at least
optional and if it has to break, it is definitely something to
document in the migration guide, isn't it?

Currently, I do not see any simple way without #ifdef jungle in the
code around to it. It is not nice.

>
> Ross

Re: busybox: passwd: applet not found

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On 20 May 2015 at 15:50, Laszlo Papp <lpapp@kde.org> wrote:

> Currently, I do not see any simple way without #ifdef jungle in the
> code around to it. It is not nice.
>

Looking at the busybox recipe reveals this:

# Whether to split the suid apps into a seperate binary
BUSYBOX_SPLIT_SUID ?= "1"

Just remember that the suid apps were being split out for good security
reasons.  There's no need for sed to have suid rights!

Ross

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 3:54 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 20 May 2015 at 15:50, Laszlo Papp <lpapp@kde.org> wrote:
>>
>> Currently, I do not see any simple way without #ifdef jungle in the
>> code around to it. It is not nice.
>
>
> Looking at the busybox recipe reveals this:
>
> # Whether to split the suid apps into a seperate binary
> BUSYBOX_SPLIT_SUID ?= "1"
>
> Just remember that the suid apps were being split out for good security
> reasons.  There's no need for sed to have suid rights!

I will not argue about security measure improvements as I agree about
them with you. However, I will debate the way this security measure is
implemented. It is distraction from the desktop world where you can
also use busybox and many use. Now, all of a sudden, we have to handle
them differently in code and scripts.

I think a less intrusive approach to implement this could have been
(and probably still not late) is to fix the rights underneath and not
by such wrappers. Such wrappers will introduce this disruption which
is not strictly needed. Well, you could say that if desktop
distributions also implement it like this, then there is no
disruption, but I think that is never going to happen if busybox
itself does not enforce it.

I think this is not a good implementation for security to remain
consistent with the rest of the world. Could it be please reconsidered
towards another solutions?

It is also good if one call tell me how to solve this differentiation
between desktop and Yocto without further code.

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 3:58 PM, Laszlo Papp <lpapp@kde.org> wrote:
> On Wed, May 20, 2015 at 3:54 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 20 May 2015 at 15:50, Laszlo Papp <lpapp@kde.org> wrote:
>>>
>>> Currently, I do not see any simple way without #ifdef jungle in the
>>> code around to it. It is not nice.
>>
>>
>> Looking at the busybox recipe reveals this:
>>
>> # Whether to split the suid apps into a seperate binary
>> BUSYBOX_SPLIT_SUID ?= "1"
>>
>> Just remember that the suid apps were being split out for good security
>> reasons.  There's no need for sed to have suid rights!
>
> I will not argue about security measure improvements as I agree about
> them with you. However, I will debate the way this security measure is
> implemented. It is distraction from the desktop world where you can
> also use busybox and many use. Now, all of a sudden, we have to handle
> them differently in code and scripts.
>
> I think a less intrusive approach to implement this could have been
> (and probably still not late) is to fix the rights underneath and not
> by such wrappers. Such wrappers will introduce this disruption which
> is not strictly needed. Well, you could say that if desktop
> distributions also implement it like this, then there is no
> disruption, but I think that is never going to happen if busybox
> itself does not enforce it.
>
> I think this is not a good implementation for security to remain
> consistent with the rest of the world. Could it be please reconsidered
> towards another solutions?
>
> It is also good if one call tell me how to solve this differentiation
> between desktop and Yocto without further code.

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.

Re: busybox: passwd: applet not found

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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.

Ross

[-- Attachment #2: Type: text/html, Size: 796 bytes --]

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 4:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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?

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

[Cc'ing Chen who invented it for the most part]

On 20 May 2015 at 17:02, Laszlo Papp <lpapp@kde.org> wrote:
> On Wed, May 20, 2015 at 3:58 PM, Laszlo Papp <lpapp@kde.org> wrote:
>> On Wed, May 20, 2015 at 3:54 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 20 May 2015 at 15:50, Laszlo Papp <lpapp@kde.org> wrote:
>>>>
>>>> Currently, I do not see any simple way without #ifdef jungle in the
>>>> code around to it. It is not nice.
>>>
>>>
>>> Looking at the busybox recipe reveals this:
>>>
>>> # Whether to split the suid apps into a seperate binary
>>> BUSYBOX_SPLIT_SUID ?= "1"
>>>
>>> Just remember that the suid apps were being split out for good security
>>> reasons.  There's no need for sed to have suid rights!

The suid rights are dropped before sed_main is entered, so the potential window
is very, very small and the affected code is pretty well understood. But we had
that argument numerous times and certain users don't follow it.

>>
>> I will not argue about security measure improvements as I agree about
>> them with you. However, I will debate the way this security measure is
>> implemented. It is distraction from the desktop world where you can
>> also use busybox and many use. Now, all of a sudden, we have to handle
>> them differently in code and scripts.
>>
>> I think a less intrusive approach to implement this could have been
>> (and probably still not late) is to fix the rights underneath and not

Can you elaborate what you imagine above?

>> by such wrappers. Such wrappers will introduce this disruption which
>> is not strictly needed. Well, you could say that if desktop
>> distributions also implement it like this, then there is no
>> disruption, but I think that is never going to happen if busybox
>> itself does not enforce it.
>>
>> I think this is not a good implementation for security to remain
>> consistent with the rest of the world. Could it be please reconsidered
>> towards another solutions?
>>
>> It is also good if one call tell me how to solve this differentiation
>> between desktop and Yocto without further code.
>
> 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.

Just don't set the SPLIT thing and all is well again.

Or set CONFIG_FEATURE_INDIVIDUAL so you get a shared libbusybox with
a gazillion small binaries linked to that. Not a fancy thing to do, granted.

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

On 20 May 2015 at 17:09, Laszlo Papp <lpapp@kde.org> wrote:
> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On 20 May 2015 at 17:09, Laszlo Papp <lpapp@kde.org> wrote:
>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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?

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

On 20 May 2015 at 17:20, Laszlo Papp <lpapp@kde.org> wrote:
> On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer
> <rep.dot.nop@gmail.com> wrote:
>> On 20 May 2015 at 17:09, Laszlo Papp <lpapp@kde.org> wrote:
>>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>>
>>>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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.

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On 20 May 2015 at 17:20, Laszlo Papp <lpapp@kde.org> wrote:
>> On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer
>> <rep.dot.nop@gmail.com> wrote:
>>> On 20 May 2015 at 17:09, Laszlo Papp <lpapp@kde.org> wrote:
>>>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>>>
>>>>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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?

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp <lpapp@kde.org> wrote:
>On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer
><rep.dot.nop@gmail.com> wrote:
>> On 20 May 2015 at 17:20, Laszlo Papp <lpapp@kde.org> wrote:
>>> On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer
>>> <rep.dot.nop@gmail.com> wrote:
>>>> On 20 May 2015 at 17:09, Laszlo Papp <lpapp@kde.org> wrote:
>>>>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross
><ross.burton@intel.com> wrote:
>>>>>>
>>>>>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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,

Re: busybox: passwd: applet not found

[Laszlo Papp]

On Wed, May 20, 2015 at 4:48 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
> On May 20, 2015 5:36:55 PM GMT+02:00, Laszlo Papp <lpapp@kde.org> wrote:
>>On Wed, May 20, 2015 at 4:25 PM, Bernhard Reutner-Fischer
>><rep.dot.nop@gmail.com> wrote:
>>> On 20 May 2015 at 17:20, Laszlo Papp <lpapp@kde.org> wrote:
>>>> On Wed, May 20, 2015 at 4:17 PM, Bernhard Reutner-Fischer
>>>> <rep.dot.nop@gmail.com> wrote:
>>>>> On 20 May 2015 at 17:09, Laszlo Papp <lpapp@kde.org> wrote:
>>>>>> On Wed, May 20, 2015 at 4:07 PM, Burton, Ross
>><ross.burton@intel.com> wrote:
>>>>>>>
>>>>>>> On 20 May 2015 at 16:02, Laszlo Papp <lpapp@kde.org> 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.

Well, I understand and appreciate that opinions vary, but if busybox
had shipped 3 binaries at the end of the build processes, then their
naming would be "standard" led by busybox upstream. Currently, there
is no way to standardize it if Yocto thinks it should be called
busybox.suid and e.g. (imaginary example) buildroot thinks it should
be called suid.busybox. This would be less than ideal if my software
has to work with both.

Yes, Denys would need to be convinced for this, but for the time
being, I do not have enough time to get it through.

Anyway, thank you for your replies. I deem them helpful and prompt.

Re: busybox: passwd: applet not found

[Bernhard Reutner-Fischer]

On May 20, 2015 5:58:32 PM GMT+02:00, Laszlo Papp <lpapp@kde.org> wrote:


>Well, I understand and appreciate that opinions vary, but if busybox
>had shipped 3 binaries at the end of the build processes, then their
>naming would be "standard" led by busybox upstream. Currently, there
>is no way to standardize it if Yocto thinks it should be called
>busybox.suid and e.g. (imaginary example) buildroot thinks it should
>be called suid.busybox. This would be less than ideal if my software
>has to work with both.

If you can then I'd set PREFER_APPLETS and use busybox hush or busybox ash as /bin/sh with one binary and thus avoid the whole filesystem roundtrip penalties.

At least that is what one normally does anyway and which works satisfactorily in a lot if setups.

Anyway, good to see it's not a busybox or compiler bug so all is well as far as I'm concerned.

thanks,