[GH-ISSUE #1541] [Question] Linux socket_controller local permission too lax? #2624

Open
opened 2026-08-05 00:48:07 -04:00 by saavagebueno · 5 comments
Owner

Originally created by @pyamsoft on GitHub (Feb 7, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1541

The Problem

The current socket is created in the "system level" runtime directory at /var/run with world read write permission of 0666.

So What?

This can allow any random user to run commands like netbird up and netbird down and talk to the netbird daemon which is running as the root user. In particular, running netbird up --preshared-key XXX as any random user can cause the daemon to overwrite the pre-shared key field in the /etc/netbird/<name>.json

Is this a security concern?

On my own local system, I limit access to the netbird client program by limiting the /var/run/netbird.sock to 0600 (root user only) and then run sudo netbird up and sudo netbird down. Without applying this change I can login as any user and run netbird commands without sudo, or wheel group access, or anything.

Reproduce

Steps to reproduce the behavior:

  1. Be a non-root user
  2. Run netbird down
  3. Run netbird up

Expected behavior

netbird socket control should be restricted to an approved unix group or the root user. Basically, commands that use the netbird client CLI program should require root, as it is talking to a daemon that is running as root.

The /var/run/netbird.sock created on this line should be created with 0600 (user only) or 0660 (user or group) instead of 0666 (user or group or anybody)

Are you using NetBird Cloud?
Cloud

netbird version
0.25.7

Originally created by @pyamsoft on GitHub (Feb 7, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1541 # The Problem The current socket is created in the "system level" runtime directory at `/var/run` with world read write permission of 0666. ## So What? This can allow any random user to run commands like `netbird up` and `netbird down` and talk to the netbird daemon which is running as the root user. In particular, running `netbird up --preshared-key XXX` as any random user can cause the daemon to overwrite the pre-shared key field in the `/etc/netbird/<name>.json` Is this a security concern? On my own local system, I limit access to the `netbird` client program by limiting the `/var/run/netbird.sock` to 0600 (root user only) and then run `sudo netbird up` and `sudo netbird down`. Without applying this change I can login as any user and run netbird commands without sudo, or wheel group access, or anything. ## Reproduce Steps to reproduce the behavior: 1. Be a non-root user 2. Run `netbird down` 3. Run `netbird up` **Expected behavior** `netbird` socket control should be restricted to an approved `unix group` or the root user. Basically, commands that use the `netbird` client CLI program should require root, as it is talking to a daemon that is running as root. The `/var/run/netbird.sock` created on [this line](https://github.com/netbirdio/netbird/blob/main/client/cmd/service_controller.go#L51) should be created with `0600` (user only) or `0660` (user or group) instead of `0666` (user or group or anybody) **Are you using NetBird Cloud?** Cloud **netbird version** 0.25.7
saavagebueno added the bugfeature-requestsecuritytriage-needed labels 2026-08-05 00:48:08 -04:00
Author
Owner

@nazarewk commented on GitHub (Apr 18, 2025):

marking this both as a "security bug" and a feature-request because it would involve a significant rework of installation procedure and the way GUI communicated with the daemon.

<!-- gh-comment-id:2815497081 --> @nazarewk commented on GitHub (Apr 18, 2025): marking this both as a "security bug" and a feature-request because it would involve a significant rework of installation procedure and the way GUI communicated with the daemon.
Author
Owner

@Blackclaws commented on GitHub (May 5, 2025):

I think the easiest way is to make this configurable. For non-shared machines this is usually not a big issue as the logged in user is usually the one managing netbird. It could be an attack surface however as a script could just manipulate netbird to connect to a different network, thus allowing external access to that machine by the attacker.

The main problem where this comes into play is shared machines where you don't just have a single user but many that might potentially interfere with one another.

Workaround: Since the daemon-addr is already configurable it can be put into a directory that is not world readable even if the permissions of the socket itself are permissible.

<!-- gh-comment-id:2850742914 --> @Blackclaws commented on GitHub (May 5, 2025): I think the easiest way is to make this configurable. For non-shared machines this is usually not a big issue as the logged in user is usually the one managing netbird. It _could_ be an attack surface however as a script could just manipulate netbird to connect to a different network, thus allowing external access to that machine by the attacker. The main problem where this comes into play is shared machines where you don't just have a single user but many that might potentially interfere with one another. Workaround: Since the daemon-addr is already configurable it can be put into a directory that is _not_ world readable even if the permissions of the socket itself are permissible.
Author
Owner

@nazarewk commented on GitHub (May 5, 2025):

Workaround: Since the daemon-addr is already configurable it can be put into a directory that is not world readable even if the permissions of the socket itself are permissible.

This is exactly what I'm doing myself, but it prevents the GUI from communicating with the daemon when cutting off access to the current user.

I think the easiest way is to make this configurable.

Might be the best solution indeed.

<!-- gh-comment-id:2850801928 --> @nazarewk commented on GitHub (May 5, 2025): > Workaround: Since the daemon-addr is already configurable it can be put into a directory that is _not_ world readable even if the permissions of the socket itself are permissible. This is exactly what I'm doing myself, but it prevents the GUI from communicating with the daemon when cutting off access to the current user. > I think the easiest way is to make this configurable. Might be the best solution indeed.
Author
Owner

@Blackclaws commented on GitHub (May 5, 2025):

I think if there was an option to allow choosing a group for the socket and then making it only 0660 that would also solve the problem as users could then be added to that group, circumventing the UI problem and restricting access to peopel of the chosen group.

<!-- gh-comment-id:2850825453 --> @Blackclaws commented on GitHub (May 5, 2025): I think if there was an option to allow choosing a group for the socket and then making it only 0660 that would also solve the problem as users could then be added to that group, circumventing the UI problem and restricting access to peopel of the chosen group.
Author
Owner

@lotheac commented on GitHub (Jan 4, 2026):

In the Alpine packaging, we create a netbird group and run the daemon as root:netbird with a patch that sets the socket permissions to 0660. The end user expectation is that unprivileged users must be added to that group to allow them to control the daemon.

<!-- gh-comment-id:3708673887 --> @lotheac commented on GitHub (Jan 4, 2026): In the Alpine packaging, we create a `netbird` group and run the daemon as `root:netbird` with [a patch that sets the socket permissions to `0660`](https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/netbird/unix-socket-permissions.patch). The end user expectation is that unprivileged users must be added to that group to allow them to control the daemon.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#2624