Mail archive
alpine-aports

Re: [alpine-aports] main/busybox: split package into core and suid subpackages

From: Natanael Copa <ncopa_at_alpinelinux.org>
Date: Thu, 22 Oct 2015 18:11:11 +0200

On Sat, 17 Oct 2015 16:46:57 +0200
Christian Kampka <christian_at_kampka.net> wrote:

> Hi,
>
> since this patch probably needs some explanation, I'd like to give an
> explanation to why I'd like to see this accepted. The current
> structure of the busybox packages, which includes the bbsuid binary
> as well as busybox forces every alpine installation to include the
> suid binary to provide functionalities like mount, passwd or su. If
> alpine is run as a chroot or docker container or likewise
> installation , which is no longer uncommon these days, having suid
> binaries included in installation should no longer be required and is
> imo quite undesirable if you think about security.

Makes perfect sense.

 
> The proposed patch splits the busybox package into two subpackages,
> busybox-core and busybox-suid. The core package contains everything
> that is currently included in the busybox package except for the
> bbsuid binary. This will be shipped via the busybox-suid package. The
> busybox package will be turned into a metapackage that pulls in
> busybox-core and busybox-suid, so for most use cases nothing will
> change except for those installations that desire it explicitly.

I wonder if we somehow can solve this with totally 2 packages:
  busybox + busybox-suid
instead of totally 3:
  busybox-core + busybox-suid + busybox.

We could for example add busybox-suid as a dependency to alpine-base,
or assume that busybox-suid is needed if some other package like openrc
is installed and have install_if="busybox=$pkgver openrc". I wonder
what happens then, if you "apk add !busybox-suid" to opt out?

I suppose the most critical thing we want avoid is someone end up
locked out from remote box due to 'su' not working after an upgrade.

> I am aware that alot of packages currently depend on the busybox
> package. I think it would be feasable enough to update those step by
> step to required only the subpackages they really need to depend on
> (which probably is not or should not be suid in most cases).
>
> I'm looking forward to your thoughts.


>
> Cheers,
> Christian
>
>
>
> ---
> Unsubscribe: alpine-aports+unsubscribe_at_lists.alpinelinux.org
> Help: alpine-aports+help_at_lists.alpinelinux.org
> ---
>



---
Unsubscribe:  alpine-aports+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-aports+help_at_lists.alpinelinux.org
---
Received on Thu Oct 22 2015 - 18:11:11 GMT