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.
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 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@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
[alpine-aports] [PATCH] main/busybox: split package into core and suid subpackages
On Sat, 17 Oct 2015 16:46:57 +0200
Christian Kampka <christian@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@lists.alpinelinux.org> Help: alpine-aports+help@lists.alpinelinux.org> --->
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
>> > 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.>
I did not go for this option because it introduces a breaking change, but
it is certainly desirable in the long run. Since 3.3 is now in freeze, it
may be OK to possibly break dependencies here.
> 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?>
Having busybox-suid as a dependency to alpine-base is crucial, but I think
we need to take care of packages that really require it, eg. mkinitfs
without suid could lead to really interesting problems. Having a
metapackage for the transition would soften the blow.
I don't have the overview yet to really offer a qualified opinion here.
> 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.>
Yes, definitely.
Let me know what you decide is the best way to proceed, I'll make the
necessary modifications to the patch.
Thanks for reviewing this.
Cheers,
Christian
On Thu, 22 Oct 2015 18:39:30 +0000
Christian Kampka <christian@kampka.net> wrote:
> >> > > 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.> >> > I did not go for this option because it introduces a breaking change, but> it is certainly desirable in the long run. Since 3.3 is now in freeze, it> may be OK to possibly break dependencies here.> > > > > 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?> >> > Having busybox-suid as a dependency to alpine-base is crucial,
If we can let alpine-base depend on busybox-suid then I think we will
be fine and can probably just drop the busybox-core package.
> but I think> we need to take care of packages that really require it, eg. mkinitfs> without suid could lead to really interesting problems.
How? the suid binaries are only:
"/bin/mount",
"/bin/ping",
"/bin/ping6",
"/bin/umount",
"/usr/bin/crontab",
"/usr/bin/passwd",
"/usr/bin/su",
"/usr/bin/traceroute",
mkinitfs needs to run as root already so it should not need elevate any
privileges and thus should not need anything suid root.
I think the only things that may need suid are things like ping/ping6
(any scripts using ping?) and interactive use like su and passwd.
I don't think it is simple to find out what packages that actually
needs suid. Even postgresql init.d script uses su but I expect su work
without suid in that case because it will reduce permissions from root
to user 'postgres'.
> Having a metapackage for the transition would soften the blow.> I don't have the overview yet to really offer a qualified opinion> here.
What I'd like to do is avoid the busbyox-core vs busybox package. If we
introduce the busybox-core package and other packages start depend on
it, then we will have problems getting rid of it in future.
> > 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.> >> > Yes, definitely.> Let me know what you decide is the best way to proceed, I'll make the> necessary modifications to the patch.> Thanks for reviewing this.
I think, split bbsuid to separate package and adding it as a dependency
to alpine-base should work.
Or am I missing something?
> Cheers,> Christian
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
Re: [alpine-aports] main/busybox: split package into core and suid
Hi,
> I think, split bbsuid to separate package and adding it as a dependency> to alpine-base should work.> Or am I missing something?
Actually, I was under the assumption that no bbsuid meant no su,ping,passwd,etc. symlinks either,
but I somehow missed the fact that busybox will of course create those without suid bit.
That said, I agree that having just busybox and busybox-suid would be the best way to proceed.
I have reworked the patch accordingly.
Cheers,
Christian
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
[alpine-aports] [PATCH] main/busybox: split package into core and suid subpackages