Hello,

At present, Alpine does not ship kernels that are eBPF enabled.  An
increasing amount of tools are dependent on eBPF, such as the support
for VRFs in iproute2.  Accordingly, I would like to enable eBPF
support for the root user only.

I believe that restricting eBPF to privileged users does not introduce
any new access or privilege to those users that does not already exist.
If you have to be root to make use of the bpf(2) syscall, then you
have to have already rooted the machine in order for eBPF to be useful
to you.  There is a sysctl we can enable which locks bpf(2) down to
root usage only, and I propose that we enable it by default: users who
wish to expose eBPF to unprivileged users may adjust their configuration
to do so.  This would involve placing a warning in the appropriate
configuration file that notes that eBPF could be potentially used by
an unprivileged user to compromise the machine.

Overall, I believe that exposing eBPF to the root user can be used to
enable many security wins in Alpine, such as making it easy to use
VRFs to isolate the management plane from the application plane, e.g.
placing sshd into vrf-mgmt and nginx into vrf-prod or similar.  eBPF
programs can also be used in place of netfilter, allowing for more
powerful packet filtering possibilities.  While those are not yet
realized, putting these tools in the hands of the Alpine community
will allow us to realize both of these possibilities in the future,
possibly in the 3.12 release window (as it is still quite early!)

If there are no objections to this change, I will roll it out this
week.

Thanks,
Ariadne

+1

On Tue, 2020-02-11 at 09:56 +0000, Ariadne Conill wrote:
> Hello,
> 
> At present, Alpine does not ship kernels that are eBPF enabled.  An
> increasing amount of tools are dependent on eBPF, such as the support
> for VRFs in iproute2.  Accordingly, I would like to enable eBPF
> support for the root user only.
> 
> I believe that restricting eBPF to privileged users does not
> introduce
> any new access or privilege to those users that does not already
> exist.
> If you have to be root to make use of the bpf(2) syscall, then you
> have to have already rooted the machine in order for eBPF to be
> useful
> to you.  There is a sysctl we can enable which locks bpf(2) down to
> root usage only, and I propose that we enable it by default: users
> who
> wish to expose eBPF to unprivileged users may adjust their
> configuration
> to do so.  This would involve placing a warning in the appropriate
> configuration file that notes that eBPF could be potentially used by
> an unprivileged user to compromise the machine.
> 
> Overall, I believe that exposing eBPF to the root user can be used to
> enable many security wins in Alpine, such as making it easy to use
> VRFs to isolate the management plane from the application plane, e.g.
> placing sshd into vrf-mgmt and nginx into vrf-prod or similar.  eBPF
> programs can also be used in place of netfilter, allowing for more
> powerful packet filtering possibilities.  While those are not yet
> realized, putting these tools in the hands of the Alpine community
> will allow us to realize both of these possibilities in the future,
> possibly in the 3.12 release window (as it is still quite early!)
> 
> If there are no objections to this change, I will roll it out this
> week.
> 
> Thanks,
> Ariadne

+1

On Wed, 12 Feb 2020 at 23:59, Nathan Angelacos <nangel@alpinelinux.org> wrote:
>
> +1
>
> On Tue, 2020-02-11 at 09:56 +0000, Ariadne Conill wrote:
> > Hello,
> >
> > At present, Alpine does not ship kernels that are eBPF enabled.  An
> > increasing amount of tools are dependent on eBPF, such as the support
> > for VRFs in iproute2.  Accordingly, I would like to enable eBPF
> > support for the root user only.
> >
> > I believe that restricting eBPF to privileged users does not
> > introduce
> > any new access or privilege to those users that does not already
> > exist.
> > If you have to be root to make use of the bpf(2) syscall, then you
> > have to have already rooted the machine in order for eBPF to be
> > useful
> > to you.  There is a sysctl we can enable which locks bpf(2) down to
> > root usage only, and I propose that we enable it by default: users
> > who
> > wish to expose eBPF to unprivileged users may adjust their
> > configuration
> > to do so.  This would involve placing a warning in the appropriate
> > configuration file that notes that eBPF could be potentially used by
> > an unprivileged user to compromise the machine.
> >
> > Overall, I believe that exposing eBPF to the root user can be used to
> > enable many security wins in Alpine, such as making it easy to use
> > VRFs to isolate the management plane from the application plane, e.g.
> > placing sshd into vrf-mgmt and nginx into vrf-prod or similar.  eBPF
> > programs can also be used in place of netfilter, allowing for more
> > powerful packet filtering possibilities.  While those are not yet
> > realized, putting these tools in the hands of the Alpine community
> > will allow us to realize both of these possibilities in the future,
> > possibly in the 3.12 release window (as it is still quite early!)
> >
> > If there are no objections to this change, I will roll it out this
> > week.
> >
> > Thanks,
> > Ariadne
>


-- 
Richard Mortier
mort@cantab.net

Hi!


> 11. feb. 2020 kl. 06:56 skrev Ariadne Conill <ariadne@dereferenced.org>:
> 
> Hello,
> 
> At present, Alpine does not ship kernels that are eBPF enabled.  An
> increasing amount of tools are dependent on eBPF, such as the support
> for VRFs in iproute2.  Accordingly, I would like to enable eBPF
> support for the root user only.
> 
> I believe that restricting eBPF to privileged users does not introduce
> any new access or privilege to those users that does not already exist.
> If you have to be root to make use of the bpf(2) syscall, then you
> have to have already rooted the machine in order for eBPF to be useful
> to you.  There is a sysctl we can enable which locks bpf(2) down to
> root usage only, and I propose that we enable it by default: users who
> wish to expose eBPF to unprivileged users may adjust their configuration
> to do so.  This would involve placing a warning in the appropriate
> configuration file that notes that eBPF could be potentially used by
> an unprivileged user to compromise the machine.

My biggest complaint against eBPF has been that it opens up a new attack vector, that cannot be disabled with a boot option or sysctl. There have been some CVE related to this already.

> Overall, I believe that exposing eBPF to the root user can be used to
> enable many security wins in Alpine, such as making it easy to use
> VRFs to isolate the management plane from the application plane, e.g.
> placing sshd into vrf-mgmt and nginx into vrf-prod or similar.  eBPF
> programs can also be used in place of netfilter, allowing for more
> powerful packet filtering possibilities.  While those are not yet
> realized, putting these tools in the hands of the Alpine community
> will allow us to realize both of these possibilities in the future,
> possibly in the 3.12 release window (as it is still quite early!)

I think eBPF is a generally scary feature and we should not be too quick to enable. I guess there have been enough time now for it to mature, so I think we can enabled it.

> If there are no objections to this change, I will roll it out this
> week.

Seems like it was pushed already. For the record, I gave my ok to enable this to Carlo in private before that happened. I guess it would have been better if I responded on the email earlier. Sorry for that.

Thanks!

-nc

> 
> Thanks,
> Ariadne