Firejail 0.9.50 is out

[Fred Barclay]

For those of us who install Firejail directly from the developer rather than through the Mint repos, Firejail 0.9.50 was released on September 7th. It comes with 41 new profiles for applications, and lots of bug fixes. I'm personnally happiest about the new --disable-mnt, --novideo, and --memory-deny-write-execute features.
Quote from the release notes:

* modif: --output split in two commands, --output and --output-stderr
* feature: per-profile disable-mnt (--disable-mnt)
* feature: per-profile support to set X11 Xephyr screen size (--xephyr-screen)
* feature: private /lib directory (--private-lib)
* feature: disable CDROM/DVD drive (--nodvd)
* feature: disable DVB devices (--notv)
* feature: --profile.print
* enhancement: print all seccomp filters under --debug
* enhancement: /proc/sys mounting
* enhancement: rework IP address assingment for --net options
* enhancement: support for newer Xpra versions (2.1+) -
set xpra-attach yes in /etc/firejail/firejail.config
* enhancement: all profiles use a standard layout style
* enhancement: create /usr/local for firecfg if the directory doesn't exist
* enhancement: allow full paths in --private-bin
* seccomp feature: --memory-deny-write-execute
* seccomp feature: seccomp post-exec
* seccomp feature: block secondary architecture (--seccomp.block_secondary)
* seccomp feature: seccomp syscall groups
* seccomp enhancement: print all seccomp filters under --debug
* seccomp enhancement: default seccomp list update
* new profiles: curl, mplayer2, SMPlayer, Calibre, ebook-viewer, KWrite,
* new profiles: Geary, Liferea, peek, silentarmy, IntelliJ IDEA,
* new profiles: Android Studio, electron, riot-web, Extreme Tux Racer,
* new profiles: Frozen Bubble, Open Invaders, Pingus, Simutrans, SuperTux
* new profiles: telegram-desktop, arm, rambox, apktool, baobab, dex2jar, gitg,
* new profiles: hashcat, obs, picard, remmina, sdat2img, soundconverter
* new profiles: truecraft, gnome-twitch, tuxguitar, musescore, neverball
* new profiles: sqlitebrowse, Yandex Browser, minetest
* bugfixes

To update/install, go to https://sourceforge.net/projects/fireja ... /firejail/. Choose firejail_0.9.50_1_amd64.deb if you're running 64-bit Mint; firejail_0.9.50_1_i386.deb for 32-bit Ming. Also, please verify your download using the instructions (look under Checksums on the bottom of the page).

Cheers!
Fred

[xenopeek]

Some interesting new options. I think the profiles should be reworked though.

For example the firefox.profile file uses a mix of noblacklist and whitelist to indicate which files and directories in your home directory it needs access to. It includes the disable-programs.inc file to backlist a huge pile of files and directories in your home directory, some of which get overruled with the noblacklist rules in the firefox.profiles. I don't understand this Why is the firefox.profile not only using whitelist rules to indicate what it should have access to? Doesn't that give the exact same result as blacklisting a pile and then noblacklisting what you do need?

[kdemeoz]

Hi Fred

I've updated my 0.9.48 to 0.9.50 nearly a fortnight ago. When still running .48, & again since .50, i have tried multiple ways to run an AppImage [KeePassXC-2.2.0-x86_64.AppImage] in FJ. The best i was able to achieve, which is still not acceptable to me, is that when launched with:

Code: Select all

firejail --appimage --protocol=unix -- KeePassXC-2.2.0-x86_64.AppImage

... KPXC does launch, obeys my Plasma desktop theming aesthetics, does find my database, does save data edits I make, BUT... when i try to change any Settings:

Code: Select all

"Access error for config file /home/kdemeoz/.config/keepassxc/keepassxc.ini"

I've tried myriad other FJ options [all documented, but i won't bother you with them here unless needed], but all achieved varying worse outcomes, right down to not launching at all.

Do you know if it is possible to run AppImages in FJ which achieve 100% functionality, other than of course the specific functions intended to be blocked by FJ?

PS-1: I have tried multiple times, since 4 Sept, to post a query to netblue30 in https://firejail.wordpress.com/features ... nt-page-1/ , but in every instance my post vanished into the ether & never subsequently materialised.

PS-2: I have also extensively experimented with the KPXC Snap package in FJ, but all those efforts yielded even poorer outcomes.

[Fred Barclay]

Some interesting new options. I think the profiles should be reworked though.

Well, yes... and no. I think definitely it would be nice to be able to rely exclusively on whitelists some day. But at the current stage of development, we're still needing to have a balancing act between blacklists and whitelists.

[xenopeek]

For files outside the home directory I understand. What's the difference between whitelisting 1 file in your home directory and blacklisting everything but that one file? I thought that did the same—if you whitelist something in your home directory, everything that isn't whitelisted gets effectively blacklisted in your home directory. I'm eager to understand what I'm overlooking.

For example if I run firejail --noprofile --whitelist=~/.cache/mozilla all I see in the sandbox doing a tree -a is:

Code: Select all

.
├── .bashrc
├── .cache
│   └── mozilla
│       └── firefox
│           ├── ...
│           ...
│
├── .config
│   └── pulse
│       └── client.conf
└── .Xauthority

The .bashrc, .config/pulse/client.conf and .Xauthority get created after starting the sandbox.

What does blacklisting directories add to this, when if you don't whitelist them they don't exist in the sandbox anyway? I don't understand What makes the difference?

[Fred Barclay]

What does blacklisting directories add to this, when if you don't whitelist them they don't exist in the sandbox anyway? I don't understand What makes the difference?

It appears you are right. I'm currently experimenting with an (almost) whitelist-only Firefox profile.

One challenge right now is time. Converting profiles that are overly-complicated but do work to whitelist-only profiles will take a lot of testing time.

[xenopeek]

One challenge right now is time. Converting profiles that are overly-complicated but do work to whitelist-only profiles will take a lot of testing time.

I'm not disputing it will take time or that the profiles can be a puzzle to untangle Thanks for having a look.

If I'm right, and I guess from your response there is a chance of that, at least the profiles that include the file disable-programs.inc and have a whitelist rule are easy to convert. Because the blacklist rules in the file disable-programs.inc don't do anything — those are all for directories in the home directory and because the profile already has a whitelist rule those directories were already effectively blacklisted.

Converting is as simple as removing the disable-programs.inc include and change all the noblacklist rules in the profile to whitelist rules (as the noblacklist rule was there to override the blacklist rule in the inc file). That can be scripted I'm happy to help on this.

This finds all the profiles that can be safely converted:

Code: Select all

comm -12 <(grep -l "^include /etc/firejail/disable-programs.inc" /etc/firejail/*.profile) <(grep -l "^whitelist " /etc/firejail/*.profile)

Because any profile that has a whitelist rule already blacklists everything else in the home directory. So additional blacklist rules on the home directory don't do anything. So any profile that includes the disable-programs.inc file and has a whitelist rule doesn't need blacklist rules for the home directory. Just convert the noblacklist rules in the profile to whitelist rules and it should be the same files and directories in the home directory that are visible in the sandbox.

Here's the list of files from above command, which I think can be converted:

Code: Select all

/etc/firejail/0ad.profile
/etc/firejail/abrowser.profile
/etc/firejail/arm.profile
/etc/firejail/aweather.profile
/etc/firejail/bibletime.profile
/etc/firejail/brave.profile
/etc/firejail/chromium.profile
/etc/firejail/conkeror.profile
/etc/firejail/cyberfox.profile
/etc/firejail/deluge.profile
/etc/firejail/dillo.profile
/etc/firejail/dino.profile
/etc/firejail/dropbox.profile
/etc/firejail/epiphany.profile
/etc/firejail/etr.profile
/etc/firejail/firefox.profile
/etc/firejail/flashpeak-slimjet.profile
/etc/firejail/franz.profile
/etc/firejail/frozen-bubble.profile
/etc/firejail/gajim.profile
/etc/firejail/galculator.profile
/etc/firejail/gnome-2048.profile
/etc/firejail/gnome-twitch.profile
/etc/firejail/google-chrome-beta.profile
/etc/firejail/google-chrome.profile
/etc/firejail/google-chrome-unstable.profile
/etc/firejail/google-play-music-desktop-player.profile
/etc/firejail/gpredict.profile
/etc/firejail/hedgewars.profile
/etc/firejail/hexchat.profile
/etc/firejail/icecat.profile
/etc/firejail/inox.profile
/etc/firejail/iridium.profile
/etc/firejail/itch.profile
/etc/firejail/ktorrent.profile
/etc/firejail/liferea.profile
/etc/firejail/Mathematica.profile
/etc/firejail/midori.profile
/etc/firejail/minetest.profile
/etc/firejail/multimc5.profile
/etc/firejail/mumble.profile
/etc/firejail/mupen64plus.profile
/etc/firejail/netsurf.profile
/etc/firejail/neverball.profile
/etc/firejail/nylas.profile
/etc/firejail/open-invaders.profile
/etc/firejail/opera-beta.profile
/etc/firejail/opera.profile
/etc/firejail/palemoon.profile
/etc/firejail/pingus.profile
/etc/firejail/polari.profile
/etc/firejail/psi-plus.profile
/etc/firejail/qbittorrent.profile
/etc/firejail/qtox.profile
/etc/firejail/quiterss.profile
/etc/firejail/qupzilla.profile
/etc/firejail/qutebrowser.profile
/etc/firejail/rambox.profile
/etc/firejail/seamonkey.profile
/etc/firejail/simutrans.profile
/etc/firejail/slack.profile
/etc/firejail/snap.profile
/etc/firejail/spotify.profile
/etc/firejail/stellarium.profile
/etc/firejail/supertux2.profile
/etc/firejail/torbrowser-launcher.profile
/etc/firejail/transmission-gtk.profile
/etc/firejail/transmission-qt.profile
/etc/firejail/truecraft.profile
/etc/firejail/uget-gtk.profile
/etc/firejail/unknown-horizons.profile
/etc/firejail/uzbl-browser.profile
/etc/firejail/virtualbox.profile
/etc/firejail/vivaldi.profile
/etc/firejail/warzone2100.profile
/etc/firejail/waterfox.profile
/etc/firejail/wesnoth.profile
/etc/firejail/xiphos.profile
/etc/firejail/xonotic.profile
/etc/firejail/xpra.profile
/etc/firejail/yandex-browser.profile
/etc/firejail/zoom.profile

That's 82 profiles. Of course it needs testing and such.

There are 200 profiles that do include the disable-programs.inc file but don't have a whitelist rule. That basically means for those programs it hasn't been figured out yet what directories they specifically need access to—only that they shouldn't access some. That's a whole different story (you can find the list of these files by running above command and replacing comm -12 with comm -23).

[Fred Barclay]

If I'm right, and I guess from your response there is a chance of that, at least the profiles that include the file disable-programs.inc and have a whitelist rule are easy to convert.

That sounds right. Definitely your help would be welcome!

There are 200 profiles that do include the disable-programs.inc file but don't have a whitelist rule. That basically means for those programs it hasn't been figured out yet what directories they specifically need access to—only that they shouldn't access some.

Right - some of them would actually do poorly with a whitelist scheme. Xreader or pluma for instance should be allowed to read files no matter their location (assuming the user already has read rights in that directory) but can be firejailed for other reasons.Sandboxing is particularly useful for things like pdf readers or media players, but we can't ship whitelists by default without significantly reducing what a user can reasonably be expected to access.

[xenopeek]

Okay. This is harder to script because as though the above is correct (replace noblacklist with whitelist and you can do away with the disable-programs.inc include) the files differ quite a bit. Some do a noblacklist, then create the directory (just in case it didn't exist), and then whitelist it. Just replacing noblacklist with whitelist won't work

[Fred Barclay]

xenopeek: There's a really good explanation of why keeping blacklists in profiles that also have whitelists is useful:
https://github.com/netblue30/firejail/i ... -331300882

If a user wants to let a program access files in another directory and they decide to disable the whitelist in a local copy, the profile will still be restricted from reading the contents of other programs (which is good!). If blacklist wasn't included and they disabled whitelist, it'd have (near) full access to their home directory (which is very bad!).

The blacklists are a failsafe in case someone disables the whitelists.

[xenopeek]

Blacklist means everything not accounted for by the profile writer is accessible. Whitelist means only that what the program needs is accessible. Only the latter provides reliable security. "this and only this is allowed", not "everything but this is allowed".

If the whitelist is too strict the program will not work—you get an issue report—you fix the profile and everybody remains happy and secure. If the blacklist is too lax the user will think they are secure while they are not—and no issue report goes to firejail promptly because nothing broke. It's not hard to imagine the profile writers haven't accounted for the directories of all possible programs with sensitive information, or that a newer version of a program with sensitive information that is accounted for changes its directories and this goes unnoticed by the profile writer, or that the user has changed where a program with sensitive information stores its information and is using a non-standard place not accounted for by the profile writer.

I would imagine if somebody wanted a program to have access to more directories in their home, they'd add a whitelist rule if the profile is only using whitelist rules—not remove all the whitelist rules from the profile or override each whitelist=path rule with a nowhitelist=path rule?

Anyway, blacklist rules make sense for system directories. Firejail isn't SELinux after all For home directory I think a default of whitelist rules is better—most certainly for dot files. But sure, for some specific programs (text editors, image viewers) you might want blacklist rules instead. On the other hand I don't think .0ad needs to be in those blacklist rules though — how is .0ad sensitive information, it's a game? I think there are a few such oddballs in the disable-programs.inc.

[Fred Barclay]

Blacklist means everything not accounted for by the profile writer is accessible. Whitelist means only that what the program needs is accessible. Only the latter provides reliable security. "this and only this is allowed", not "everything but this is allowed".

Right.

I would imagine if somebody wanted a program to have access to more directories in their home, they'd add a whitelist rule if the profile is only using whitelist rules—not remove all the whitelist rules from the profile or override each whitelist=path rule with a nowhitelist=path rule?

Here I disagree. I personally suspect they'd be more likely to remove the whitelist rules (particularly in the case of new users). In either case, keeping blacklists as-is will not lower security and may enhance it:

1. The user removes the whitelists. Without blacklists, their entire home is exposed. With blacklists (the current setup) the really secret stuff is still safe.

2. The user adds a nowhitelist rule. Nothing really changes from a security standpoint here.

For home directory I think a default of whitelist rules is better—most certainly for dot files

We have that: include /etc/firejail/whitelist-common.inc.

[Fred Barclay]

Hi Fred

I've updated my 0.9.48 to 0.9.50 nearly a fortnight ago. When still running .48, & again since .50, i have tried multiple ways to run an AppImage [KeePassXC-2.2.0-x86_64.AppImage] in FJ.

G'day kdemoz and sorry for the late reply! I'm seeing this same problem myself. Let me see what I can figure out.
Cheers!

[kdemeoz]

G'day Fred

I've still made no progress here wrt FJ & the KPXC AppImage, but [to my embarrassment] i did make a beneficial discovery belatedly about running said AI "naked". For reasons i can't justify or explain, once i knew that the "real" KPXC pgm [as installed from Repo] has full internet access if run "naked", i simply assumed... but initially failed to check... that the AI &/or Snap versions would also have naked net access. In fact, they do not. Whether by blunder or design, both those formats self-block net access, even without me explicitly blocking it with FJ.

So, whilst i still would feel more comfy running KPXC in FJ, until that does become possible [without compromising the aesthetics & functionality as mentioned], for the time being i am kinda sorta satisfied running the KPXC AI sans FJ.

FYI.

[Fred Barclay]

kdemoz: I've got a temporary workaround for running the keepassxc appimage in firejail. Beware it's kinda long!

Code: Select all

firejail --appimage --ignore=shell --private-bin=keepassxc,bash,keepassxc_env.wrapper,readlink,dirname,find,head,basename,sed,tr,env --profile=/etc/firejail/keepassxc.profile ./KeePassXC-2.2.0-x86_64.AppImage

You will, of course, need to change ./KeePassXC-2.2.0-x86_64.AppImage to the correct path and name.

[kdemeoz]

Oh Fred, FRED -- you are simply a genius. Thank you so much for solving this for me, i'm just thrilled. Never in 100 years would i have been able to deduce that solution. I made only two small tweaks to your magic; the first as ongoing testament to my paranoia, the second just to suit my PATH without me needing to relocate my AI.

Code: Select all

firejail --appimage --ignore=shell --protocol=unix --private-bin=keepassxc,bash,keepassxc_env.wrapper,readlink,dirname,find,head,basename,sed,tr,env --profile=/etc/firejail/keepassxc.profile ./bin/KeePassXC-2.2.0-x86_64.AppImage

Your magic ticks all my necessary boxes, viz: fully respects my desktop theming aesthetics, properly accesses my data file, is fully-functional [ie, including copying custom attributes to clipboard; allowing Settings edits]; & of course, actually runs in FJ. Every other iteration i'd tried, failed in at least one of those parameters.

Btw, i'm a bit intrigued by your

a temporary workaround

... implying maybe a "watch this space" possibility for a future FJ enhancement?

Many thanks, Fred.

[Fred Barclay]

Haha, no worries mate.

Btw, i'm a bit intrigued by your

a temporary workaround

... implying maybe a "watch this space" possibility for a future FJ enhancement?

I hope/think so, yes. Part of the problem was that this particular AppImage was running with the generic firejail profile rather than the keepassxc profile. Ideally it would have known to use the keepassxc profile - I think firejail normally uses the corresponding program profile for AppImages but it's not here for some reason. I've never dealt with the appimage code in firejail so I could be mistaken. I'll have to ask around.