dhclient #4691

New issue

Closed

opened 2026-05-05 10:24:47 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 10:24:47 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/netblue30/firejail/pull/3239
Author: @kris7t
Created: 2/23/2020
Status: ✅ Merged
Merged: 2/23/2020
Merged by: @smitsohu

Base: master ← Head: dhcp-client

📝 Commits (1)

9860590 Harden dhcp by checking for /sbin/dhclient

📊 Changes

1 file changed (+21 additions, -6 deletions)

View changed files

📝 src/firejail/dhcp.c (+21 -6)

📄 Description

In order to avoid picking up some random executable from $PATH and potentially running it root privileges, dhcp.c should check for /sbin/dhclient or /usr/sbin/dhclient directly. This might cause problems on distributions where dhclient is located elsewhere, but as far as I know, /sbin is the default location (and even Arch, which uses only /usr/bin, symlinks /sbin to /usr/bin). This is the same approach that netfilter.c takes when running iptables-restore.

I formulated the check for root privileges according to https://github.com/netblue30/firejail/blob/master/src/firejail/x11.c#L1103, which allows the binary to either be owned by root, or the root group. A more paranoid version would use open, fstat and fexecve to make sure ownership of the binary does not change between the stat and exec calls. On the other hand, manipulation of a binary already owned by root means the system is already compromised, so there's probably not much point to be careful about TOCTOU here. netfiler.c even skips the check altogether, and relies on /sbin being only writable by root.

Hopefully, we don't blindly execute a binary with root privileges anywhere else in the codebase.

A more meta question: what is the policy with running external executable from firejail with root privilages (even if capability and seccomp sandboxed)? The potential for introducing setuid-related vulnerabilities is high. If we want to integrate additional external tools (like xdg-dbus-proxy), we should try to keep it reasonably safe.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/netblue30/firejail/pull/3239 **Author:** [@kris7t](https://github.com/kris7t) **Created:** 2/23/2020 **Status:** ✅ Merged **Merged:** 2/23/2020 **Merged by:** [@smitsohu](https://github.com/smitsohu) **Base:** `master` ← **Head:** `dhcp-client` --- ### 📝 Commits (1) - [`9860590`](https://github.com/netblue30/firejail/commit/9860590b25e1478367650a1c5ff694abf70a5b65) Harden dhcp by checking for /sbin/dhclient ### 📊 Changes **1 file changed** (+21 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `src/firejail/dhcp.c` (+21 -6) </details> ### 📄 Description In order to avoid picking up some random executable from `$PATH` and potentially running it root privileges, `dhcp.c` should check for `/sbin/dhclient` or `/usr/sbin/dhclient` directly. This might cause problems on distributions where `dhclient` is located elsewhere, but as far as I know, `/sbin` is the default location (and even Arch, which uses only `/usr/bin`, symlinks `/sbin` to `/usr/bin`). This is the same approach that `netfilter.c` takes when running `iptables-restore`. I formulated the check for root privileges according to https://github.com/netblue30/firejail/blob/master/src/firejail/x11.c#L1103, which allows the binary to either be owned by root, or the root group. A more paranoid version would use `open`, `fstat` and `fexecve` to make sure ownership of the binary does not change between the `stat` and `exec` calls. On the other hand, manipulation of a binary already owned by root means the system is already compromised, so there's probably not much point to be careful about TOCTOU here. `netfiler.c` even skips the check altogether, and relies on `/sbin` being only writable by root. Hopefully, we don't blindly execute a binary with root privileges anywhere else in the codebase. _A more meta question: what is the policy with running external executable from firejail with root privilages (even if capability and seccomp sandboxed)?_ The potential for introducing setuid-related vulnerabilities is high. If we want to integrate additional external tools (like `xdg-dbus-proxy`), we should try to keep it reasonably safe. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

gitea-mirror

2026-05-05 10:24:47 -06:00

closed this issue
added the
pull-request
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#4691

No description provided.

Rows
Columns