Firejail: Plugins support

[KOLANICH]

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

Here are some ideas:

1. 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.
5. 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.
6. 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.
7. plugin outputs a dict specifying additional restrictions. they are cached.
8. firejail combines additional restrictions to profile-based restrictions, making sure that the resulting restrictions are stricter than the ones provided with profile

[chiraag-nataraj]

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?

[KOLANICH]

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.

[chiraag-nataraj]

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.

[topimiettinen]

@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.