github-starred/firejail

Fork 0

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

[GH-ISSUE #2908] Plugins support #1816

New issue

Closed

opened 2026-05-05 08:29:16 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 08:29:16 -06:00

Owner

Originally created by @KOLANICH on GitHub (Aug 13, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2908

I guess we may need some architecture allowing usage of standalone plugins.

Here are some ideas:
0. firejail keeps a cache in a location accessible only by a prjvileged location. this cache is a database with the following tables:
files, containing an inode, path and hash. There should be a cron job cleaning missing files from the table. Checked and updated on every execution of an executable using fj.
yara, containing a yara file name, hash and version is incremented on every file hash change.
plugins, containing a plugin name, yara, hash, version . This table is checked and filled on firejail startup.
cache containing file, plugin, plugin_version, cached_diff

a plugin in a general case is a standalone executable (elf, python script, etc) + a yara file. Plugin knows file name of its yara file. All executions of plugins are hardcorely sandboxed.
plugins input and output CBOR-serialized dictionaries to/from pipes of a caller process which numbers are passed via command line arguments.
plugins output own manifests when requested. A manifest contains a name of a yara file .
when plugin hash changes firejail updates its version and requests plugin's manifest and caches it.
an executable being called is checked in cache first; its hash must match the hash in cache and plugin version in cache must match one in plugins. If there is no cached additions to a profile, then the file is matched against all the registered yara files.
when a match is found plugins tied to this yara file are called against the executable. The following info is provided: executable file path, previous value of cached settings (null if there is no), information about the file from the db, information about yara matches.
plugin outputs a dict specifying additional restrictions. they are cached.
firejail combines additional restrictions to profile-based restrictions, making sure that the resulting restrictions are stricter than the ones provided with profile

Originally created by @KOLANICH on GitHub (Aug 13, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2908 I guess we may need some architecture allowing usage of standalone plugins. Here are some ideas: 0. firejail keeps a cache in a location accessible only by a prjvileged location. this cache is a database with the following tables: `files`, containing an `inode`, `path` and `hash`. There should be a cron job cleaning missing files from the table. Checked and updated on every execution of an executable using fj. `yara`, containing a yara file `name`, `hash` and `version` is incremented on every file hash change. `plugins`, containing a plugin `name`, `yara`, `hash`, `version` . This table is checked and filled on firejail startup. `cache` containing `file`, `plugin`, `plugin_version`, `cached_diff` 1. a plugin in a general case is a standalone executable (elf, python script, etc) + a yara file. Plugin knows file name of its `yara` file. All executions of plugins are hardcorely sandboxed. 2. plugins input and output CBOR-serialized dictionaries to/from pipes of a caller process which numbers are passed via command line arguments. 3. plugins output own manifests when requested. A manifest contains a name of a `yara` file . 4. when plugin hash changes firejail updates its version and requests plugin's manifest and caches it. 2. an executable being called is checked in `cache` first; its hash must match the `hash` in `cache` and plugin `version` in `cache` must match one in `plugins`. If there is no cached additions to a profile, then the file is matched against all the registered yara files. 3. when a match is found plugins tied to this yara file are called against the executable. The following info is provided: executable file path, previous value of cached settings (null if there is no), information about the file from the db, information about yara matches. 4. plugin outputs a dict specifying additional restrictions. they are cached. 5. firejail combines additional restrictions to profile-based restrictions, making sure that the resulting restrictions are stricter than the ones provided with profile

gitea-mirror

2026-05-05 08:29:16 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:29:19 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 15, 2019):

This honestly sounds like a major vector to introduce bugs and security vulnerabilities.

Why are plugins necessary (or even useful)? Is there a specific use-case you have in mind?

@chiraag-nataraj commented on GitHub (Sep 15, 2019): This honestly sounds like a major vector to introduce bugs and security vulnerabilities. Why are plugins necessary (or even useful)? Is there a specific use-case you have in mind?

gitea-mirror commented

2026-05-05 08:29:20 -06:00

Author

Owner

@KOLANICH commented on GitHub (Sep 16, 2019):

Automatic hardening of profiles based on binaries themselves. For example not so long ago I saw an app on GH creating a list of syscalls used in apps written in go. The proposed use case for that app was to restricting apps to ths list generated by that app to reduce attack surface in an unlike case of compromising an app in a memory-safe language (I guess a vulnr in a native lib used). I thought that it'd be nice to interface such kind of apps to firejail.
GUI configuration.

@KOLANICH commented on GitHub (Sep 16, 2019): 1. Automatic hardening of profiles based on binaries themselves. For example not so long ago I saw an app on GH creating a list of syscalls used in apps written in go. The proposed use case for that app was to restricting apps to ths list generated by that app to reduce attack surface in an unlike case of compromising an app in a memory-safe language (I guess a vulnr in a native lib used). I thought that it'd be nice to interface such kind of apps to firejail. 2. GUI configuration.

gitea-mirror commented

2026-05-05 08:29:21 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 16, 2019):

GUI configuration doesn't really require plugins per se , though. It just requires someone to track firejail's development and, if necessary, expose certain profile options based on the version of the tool (gotten through firejail --version).

As for automatic hardening, I'm still not sure I see a usecase for plugins specifically here. We have a separate script in this repo, I believe, to enumerate the syscalls used, and we have firejail --build. Currently, there are so many nuances with each profile that most of the profile generation can't really be automated...at the very least, someone has to look over it, test it out, see if it breaks a common usecase, and so on.

As you can tell, I'm very much against the idea of a plugin architecture given the nature of the tool (for the reasons I mentioned earlier). I'll let other people chime in though, since I don't want to hog the conversation here.

@chiraag-nataraj commented on GitHub (Sep 16, 2019): GUI configuration doesn't really require _plugins_ per se , though. It just requires someone to track `firejail`'s development and, if necessary, expose certain profile options based on the version of the tool (gotten through `firejail --version`). As for automatic hardening, I'm still not sure I see a usecase for plugins specifically here. We have a separate script in this repo, I believe, to enumerate the syscalls used, and we have `firejail --build`. Currently, there are so many nuances with each profile that most of the profile generation can't _really_ be automated...at the very least, someone has to look over it, test it out, see if it breaks a common usecase, and so on. As you can tell, I'm very much against the idea of a plugin architecture given the nature of the tool (for the reasons I mentioned earlier). I'll let other people chime in though, since I don't want to hog the conversation here.

gitea-mirror commented

2026-05-05 08:29:22 -06:00

Author

Owner

@topimiettinen commented on GitHub (Sep 17, 2019):

@KOLANICH's points could support having some kind of external configuration for firejail --build, firecfg or firetools UI. I fully agree with @chiraag-nataraj that support for firejail itself is too risky.

But 3rd party plugins as a way for achieving this would only lead to problems. We would need to support some kind of stable API or ABI. We couldn't test if our changes would lead to problems for the 3rd parties somewhere, perhaps closed source. For example, if we later wanted to add sandboxing to plugins or tighten it, there could be delayed complaints or reluctance to implement anything due to possible breakage. I've seen this kind of hesitation for other apps.

Configuration files of Firejail are relatively stable, so external programs should be able to generate profiles or parts of them. This could be made easier if Firejail supported drop-ins like systemd, so for example firefox.profile could be enhanced by adding snippets in /etc/firejail/firefox.profile.d/ for more static configuration and /var/lib/firejail/firefox.profile.d/ for more automatically generated configuration. The generators should not be run by Firejail, but firecfg, firetools or elsewhere, for example during package installation or every run of apt/rpm, on every boot etc.

@topimiettinen commented on GitHub (Sep 17, 2019): @KOLANICH's points could support having some kind of external configuration for `firejail --build`, `firecfg` or `firetools` UI. I fully agree with @chiraag-nataraj that support for `firejail` itself is too risky. But 3rd party plugins as a way for achieving this would only lead to problems. We would need to support some kind of stable API or ABI. We couldn't test if our changes would lead to problems for the 3rd parties somewhere, perhaps closed source. For example, if we later wanted to add sandboxing to plugins or tighten it, there could be delayed complaints or reluctance to implement anything due to possible breakage. I've seen this kind of hesitation for other apps. Configuration files of Firejail are relatively stable, so external programs should be able to generate profiles or parts of them. This could be made easier if Firejail supported drop-ins like systemd, so for example `firefox.profile` could be enhanced by adding snippets in `/etc/firejail/firefox.profile.d/` for more static configuration and `/var/lib/firejail/firefox.profile.d/` for more automatically generated configuration. The generators should not be run by Firejail, but `firecfg`, `firetools` or elsewhere, for example during package installation or every run of `apt`/`rpm`, on every boot etc.

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

No description provided.

Rows
Columns