Extended Berkeley Packet Fillter (eBPF) disabled for non-root users

Salut!

My YunoHost server

Hardware: VPS bought online /
YunoHost version: 4.3.6.2
I have access to my server : Through SSH | through the webadmin | direct access via keyboard / screen | …
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

this morning I’ve got the following e-mail from my YH server and I’m not sure what to think of it.
There was an update for crystal which I’ve applied with no issues, but it’s probably not related to eBPF.
Do you happen to have any comments on this? Can I safely ignore it? Is it probably related to an installed app or rather to YH / Linux itself? There is an issue with the Hubzilla app, but it’s present for 1 or 2 week already and this message came up only today.
Thanks for your support.

Logs: https://paste.yunohost.org/raw/iwofipaniw

Extended Berkeley Packet Fillter (eBPF)

linux-latest (105+deb10u14) buster-security; urgency=high

  * From Linux 4.19.232-1, the Extended Berkeley Packet Fillter (eBPF)
    facility is no longer enabled by default for users without the
    CAP_SYS_ADMIN capability (this normally means only the root user).

    eBPF can be used for speculative execution side-channel attacks, and
    earlier attempts to mitigate this have not completely succeeded.

    This can be overridden by setting the sysctl:

        kernel.unprivileged_bpf_disabled=0

 -- Ben Hutchings <benh@debian.org>  Mon, 07 Mar 2022 22:37:11 +0100
1 Like

:us: English

Hello, I received the same email. My understanding is that:

  • there is an update overriding the privileges of non-admin users to avoid this security hole: is it already updated or do we need to do it?
  • an edition of sysctl allows to restore the privilege of non-admin users (and thus the restoration of the flaw) with kernel.unprivileged_bpf_disabled=0 but at this time, I don’t know the command.

So as @hermann-san asks, and considering the severity of the flaw (high): could you confirm what to do please?
Thank you !


:fr: French

Bonjour, j’ai reçu le même mail ce matin. À mon avis, j’ai compris :

  • qu’il y a une mise à jour annulant les privilèges des utilisateurs non-admin pour éviter cette faille de sécurité : est-ce déjà mis à jour ou devons-nous la faire ?
  • qu’une édition du sysctl permet de rétablir le privilège des utilisateurs non-admin (et donc le rétablissement de la faille) avec kernel.unprivileged_bpf_disabled=0 mais à ce moment-là, je ne connais pas la commande.

Donc comme le demande @hermann-san, et vu la gravité de la faille (haute) : pourriez-vous nous confirmer que faire svp ?
Merci !

1 Like

The same for me, same message. After that the diagnoses sent me a message per day, that port 25 outgoing would be blocked by a provider’s firewall.

I got in contact with my provider and he answered, that port 25 is not blocked. So it seems likely, that there is a connection between these two issues?

I’m in no way an expert in these topics, just guessing.

Martin

1 Like

I did set

sysctl -w kernel.unprivileged_bpf_disabled=0

and now everything works again. This is a pretty bad bug, as it seems. :-/

Til the bug is fixed I set this to /etc/sysctl.d/local.conf

kernel.unprivileged_bpf_disabled=0

Although, it has a reason, why this change happened… So may not be the final solution.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.