[GH-ISSUE #1376] Grsecurity, Firejail and Bridge Networking #940

Open
opened 2026-05-05 07:11:55 -06:00 by gitea-mirror · 3 comments
Owner

Originally created by @biergaizi on GitHub (Jul 13, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1376

Grsecurity, Firejail and Bridge Networking

This issue is intended to document a problem on Grsecurity's kernel. It is not an issue of firejail at all. I just want to document this issue to help others who may encounter the same problem in the future.

firejail is a sandboxing program which utilizes the namespace functionality of the Linux kernel.

One of its feature is creating an isolated the network namespace,

# ip link add br0 type bridge
# ifconfig br0 10.1.0.1/24
$ firejail --net=br0

Unfortunately, it doesn't work with Grsecurity kernel. If firejail is executed as root instead, it will work as expected.

From the debug log, we observe a veth interface is created by firejail for networking under normal operations.

create veth vethxxxxeth0/eth0/xxxx

but a macvlan is created instead on Grsecurity kernel without root.

root: create macvlan eth0-xxxx, parent br0

Inspecting the source code, we identified the source of the problem in network_main.c.

// check the bridge device exists
char sysbridge[30 + strlen(br->dev)];
sprintf(sysbridge, "/sys/class/net/%s/bridge", br->dev);
struct stat s;
int rv = stat(sysbridge, &s);
if (rv == 0) {
        // this is a bridge device
        br->macvlan = 0;
}
else {
        // is this a regular Ethernet interface
        if (if_nametoindex(br->dev) > 0) {
                br->macvlan = 1;
        // [...]
}

firejail relies on information from /sys/class/net to decide whether it is a bridge device or an Ethernet interface, if CONFIG_GRKERNSEC_SYSFS_RESTRICT is enabled on a Grsecurity kernel, these files will be inaccessible by regular users to prevent information leaks.

The solution is to disable CONFIG_GRKERNSEC_SYSFS_RESTRICT in Grsecurity's kernel configuration, on a desktop system, this option should not be enabled anyway since it creates compatibility issues with many desktop programs.

Manually running chmod to hack these permissions is another solution. Since /sys/class/net contains symbol links to other directories, permissions of other directories, such as /sys/devices/virtual/net should be also changed.

Since hiding /sys is generally desirable on security-focused production servers, an alternative approach is to change the source code of firejail if feasible, e.g. add an option to allow users to choice the interface type.

Originally created by @biergaizi on GitHub (Jul 13, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1376 Grsecurity, Firejail and Bridge Networking =========================================== This issue is intended to document a problem on Grsecurity's kernel. It is not an issue of firejail at all. I just want to document this issue to help others who may encounter the same problem in the future. firejail is a sandboxing program which utilizes the namespace functionality of the Linux kernel. One of its feature is creating an isolated the network namespace, # ip link add br0 type bridge # ifconfig br0 10.1.0.1/24 $ firejail --net=br0 Unfortunately, it doesn't work with Grsecurity kernel. If firejail is executed as root instead, it will work as expected. From the debug log, we observe a `veth` interface is created by firejail for networking under normal operations. create veth vethxxxxeth0/eth0/xxxx but a `macvlan` is created instead on Grsecurity kernel without root. root: create macvlan eth0-xxxx, parent br0 Inspecting the source code, we identified the source of the problem in network_main.c. // check the bridge device exists char sysbridge[30 + strlen(br->dev)]; sprintf(sysbridge, "/sys/class/net/%s/bridge", br->dev); struct stat s; int rv = stat(sysbridge, &s); if (rv == 0) { // this is a bridge device br->macvlan = 0; } else { // is this a regular Ethernet interface if (if_nametoindex(br->dev) > 0) { br->macvlan = 1; // [...] } firejail relies on information from `/sys/class/net` to decide whether it is a bridge device or an Ethernet interface, if `CONFIG_GRKERNSEC_SYSFS_RESTRICT` is enabled on a Grsecurity kernel, these files will be inaccessible by regular users to prevent information leaks. The solution is to disable `CONFIG_GRKERNSEC_SYSFS_RESTRICT` in Grsecurity's kernel configuration, on a desktop system, this option should not be enabled anyway since it creates compatibility issues with many desktop programs. Manually running `chmod` to hack these permissions is another solution. Since `/sys/class/net` contains symbol links to other directories, permissions of other directories, such as `/sys/devices/virtual/net` should be also changed. Since hiding `/sys` is generally desirable on security-focused production servers, an alternative approach is to change the source code of firejail if feasible, e.g. add an option to allow users to choice the interface type.
Author
Owner

@Ferroin commented on GitHub (Jul 13, 2017):

Even without the grsecurity specific bit, I think adding an option to manually select the interface type is a good idea, both for completeness/testing, and because there are paranoid people like me who manually set permissions on /sys to deny access for unprivileged users even though we're not using grsecurity kernels.

<!-- gh-comment-id:315143527 --> @Ferroin commented on GitHub (Jul 13, 2017): Even without the grsecurity specific bit, I think adding an option to manually select the interface type is a good idea, both for completeness/testing, and because there are paranoid people like me who manually set permissions on /sys to deny access for unprivileged users even though we're not using grsecurity kernels.
Author
Owner

@rusty-snake commented on GitHub (Apr 1, 2020):

Anything to go here?

<!-- gh-comment-id:607322510 --> @rusty-snake commented on GitHub (Apr 1, 2020): Anything to go here?
Author
Owner

@biergaizi commented on GitHub (May 6, 2020):

@rusty-snake Nothing. Perhaps I should submit a patch then?

<!-- gh-comment-id:624765566 --> @biergaizi commented on GitHub (May 6, 2020): @rusty-snake Nothing. Perhaps I should submit a patch then?
Sign in to join this conversation.
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#940
No description provided.