github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #4845] Options to deal with open file descriptors #2793

New issue

Closed

opened 2026-05-05 09:26:53 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 09:26:53 -06:00

Owner

Originally created by @smitsohu on GitHub (Jan 11, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4845

Currently Firejail sandboxes inherit all open file descriptors from their parent process.

As far as standard streams (stdin, stdout, stderr) are concerned this is probably desired behaviour. On the other hand, passing non-standard file descriptors (> 2) into the sandbox is only rarely necessary in my experience.

IMHO Firejail should provide a mechanism to prevent accidental leakage of open file descriptors, either by default with a way to opt-out, or alternatively as an opt-in. I would like to know if there is general interest in options like

inheritfd (don't close one or more file descriptors > 2)
discard-stdin (-> /dev/null)
discard-stdout (-> /dev/null)
discard-stderr (-> /dev/null)

Originally created by @smitsohu on GitHub (Jan 11, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/4845 Currently Firejail sandboxes inherit all open file descriptors from their parent process. As far as standard streams (stdin, stdout, stderr) are concerned this is probably desired behaviour. On the other hand, passing non-standard file descriptors (> 2) into the sandbox is only rarely necessary in my experience. IMHO Firejail should provide a mechanism to prevent accidental leakage of open file descriptors, either by default with a way to opt-out, or alternatively as an opt-in. I would like to know if there is general interest in options like `inheritfd` (don't close one or more file descriptors > 2) `discard-stdin` (-> /dev/null) `discard-stdout` (-> /dev/null) `discard-stderr` (-> /dev/null)

gitea-mirror

2026-05-05 09:26:53 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 09:26:56 -06:00

Author

Owner

@ghost commented on GitHub (Jan 11, 2022):

I'd say any prevention of accidental leakage is a welcome enhancement and the proposed options sound great.

On the other hand, passing non-standard file descriptors (> 2) into the sandbox is only rarely necessary in my experience.

Just out of curiosity, could you provide an example of such a case?

@ghost commented on GitHub (Jan 11, 2022): I'd say any prevention of accidental leakage is a welcome enhancement and the proposed options sound great. > On the other hand, passing non-standard file descriptors (> 2) into the sandbox is only rarely necessary in my experience. Just out of curiosity, could you provide an example of such a case?

gitea-mirror commented

2026-05-05 09:26:57 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 11, 2022):

Is there anything bad expect that you can read/write on that fd?

Just out of curiosity, could you provide an example of such a case?

firejail --noprofile --shell=none --private-bin=gnome-2048 /proc/self/fd/5 -l /usr/bin 5</usr/bin/ls

@rusty-snake commented on GitHub (Jan 11, 2022): Is there anything bad expect that you can read/write on that fd? > Just out of curiosity, could you provide an example of such a case? `firejail --noprofile --shell=none --private-bin=gnome-2048 /proc/self/fd/5 -l /usr/bin 5</usr/bin/ls`

gitea-mirror commented

2026-05-05 09:26:57 -06:00

Author

Owner

@reinerh commented on GitHub (Jan 11, 2022):

Is there anything bad expect that you can read/write on that fd?

Open FDs are bad in simple chroots, as you can use them to escape with fchdir(fd) (if fd is outside). There is probably other bad stuff you can do with open FDs to get information from outside the jail.

Not sure how firejail behaves with --chroot. It's probably best to close everything.

@reinerh commented on GitHub (Jan 11, 2022): > Is there anything bad expect that you can read/write on that fd? Open FDs are bad in simple chroots, as you can use them to escape with `fchdir(fd)` (if `fd` is outside). There is probably other bad stuff you can do with open FDs to get information from outside the jail. Not sure how firejail behaves with `--chroot`. It's probably best to close everything.

gitea-mirror commented

2026-05-05 09:26:58 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 11, 2022):

Yeah, if the open fd refers to a directory you can fchdir, openat, execveat, ... which is close to full filesystem access. But if it refers to a file? Is there something like get_basedirfd_of_fd? If anyone knows more, I'm interested.

@rusty-snake commented on GitHub (Jan 11, 2022): Yeah, if the open fd refers to a directory you can `fchdir`, `openat`, `execveat`, ... which is close to full filesystem access. But if it refers to a file? Is there something like `get_basedirfd_of_fd`? If anyone knows more, I'm interested.

gitea-mirror commented

2026-05-05 09:26:58 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 11, 2022):

Is there anything bad expect that you can read/write on that fd?

It depends on the file descriptor. As a rule of thumb everything that can be done with a file descriptor outside the sandbox can be done also inside the sandbox. This includes reading/writing to files or interprocess communication.

Many file descriptors (those that are obtained by actually opening a file) are bound to a mount point, and inherited file descriptors necessarily refer to mount points outside the sandbox. So a worst case scenario would be a file descriptor that allows to bypass a blacklist or read-only directive, or if it refers to a directory to fchdir out of the sandbox entirely.

Pythons subprocess module by the way closes all non-standard file descriptors by default, or at least that is my understanding. If this is ok for a general purpose Python module, I think it should be okay'ish for Firejail as well.

Is there something like get_basedirfd_of_fd

Hopefully not!
If it exists, most if not all of the common sandboxing tools will have a problem, because, as you say, that would be equal to full unrestricted filesystem access.

@smitsohu commented on GitHub (Jan 11, 2022): > Is there anything bad expect that you can read/write on that fd? It depends on the file descriptor. As a rule of thumb everything that can be done with a file descriptor outside the sandbox can be done also inside the sandbox. This includes reading/writing to files or interprocess communication. Many file descriptors (those that are obtained by actually opening a file) are bound to a mount point, and inherited file descriptors necessarily refer to mount points outside the sandbox. So a worst case scenario would be a file descriptor that allows to bypass a `blacklist` or `read-only` directive, or if it refers to a directory to `fchdir` out of the sandbox entirely. Pythons `subprocess` module by the way closes all non-standard file descriptors by default, or at least that is my understanding. If this is ok for a general purpose Python module, I think it should be okay'ish for Firejail as well. > Is there something like `get_basedirfd_of_fd` Hopefully not! If it exists, most if not all of the common sandboxing tools will have a problem, because, as you say, that would be equal to full unrestricted filesystem access.

gitea-mirror commented

2026-05-05 09:26:59 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 12, 2022):

MHO Firejail should provide a mechanism to prevent accidental leakage of open file descriptors, either by default with a way to opt-out

It is rarely used, so we should prevent it by default + some command line option to opt-out.

@netblue30 commented on GitHub (Jan 12, 2022): > MHO Firejail should provide a mechanism to prevent accidental leakage of open file descriptors, either by default with a way to opt-out It is rarely used, so we should prevent it by default + some command line option to opt-out.

gitea-mirror commented

2026-05-05 09:26:59 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 17, 2022):

On the other hand, passing non-standard file descriptors (> 2) into the sandbox is only rarely necessary in my experience.

Just out of curiosity, could you provide an example of such a case?

I used man -wK 1 'file descriptor' for a first impression. There are only a few interesting hits, like for example in the git, git-remote-fd, gpg, openssl or tar man pages.

@smitsohu commented on GitHub (Jan 17, 2022): >> On the other hand, passing non-standard file descriptors (> 2) into the sandbox is only rarely necessary in my experience. >> > Just out of curiosity, could you provide an example of such a case? I used `man -wK 1 'file descriptor'` for a first impression. There are only a few interesting hits, like for example in the `git`, `git-remote-fd`, `gpg`, `openssl` or `tar` man pages.

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#2793

No description provided.

Rows
Columns