firejail / seccomp / More Options for Program Containment

Discussed ways to make programs run under Firejail automatically out of the box. This can be taken further by optionally making other programs without a profile run seamlessly under the generic containment profile. Also mentioned Oz’s technique in tackling this if it turns out my idea can’t work.

1 Like
1 Like

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822693

1 Like

Dev/Firejail - Kicksecure

To integrate with Firejail, the script developed by Yawning is meant to replace the one in this path: /home/user/.tb/tor-browser/Browser/start-tor-browser

Can you open a ticket against TPO please to merge firejail start-tor-browser into Tor Browser? In a - if firejail is installed, use it - otherwise just function as usual, there should no objection. And cc yawning.

1 Like

@Patrick

Would like your comments on some points: Dev/Firejail - Kicksecure

Please try to avoid these strange links. They are probably a bug. Something mediawiki messed up since the upgrade. I don’t think this is something they did on purpose. Please use the normal links. You can get them by reloading the page. Ex: Dev/Firejail - Kicksecure

Firejail should probably get its own Whonix helper package to include custom profiles (Yawning’s TBB). Xpra dependency should be coded there.

I’d say it to GitHub - Kicksecure/apparmor-profile-torbrowser: AppArmor profile for The Tor Browser Bundle (TBB) - https://www.whonix.org/wiki/AppArmor - for better security (hardening).. (The clean way would be to rename the packatge to containment-profile-torbrowser but let’s skip this overhead.)

Changes to TBB launchers required.

This is very bad because these come with TBB which has no Debian package. And TBB internal updater does not support post update hooks (feature request against TBB exists but will not be implemented). So I would not know how to keep it active after TBB upgrades unless inventing a hack inotifywait or so (but even then there could be race conditions). Launches changes really should be submitted upstream.

Decide on whether to introduce pinned packages

Decide if firecfg should be scripted to enable all profiles by default.

Please submit a feature request against upstream firejail or Debian. (Whenever more appropriate, probably Debian?) This also makes a lot more sense upstream than Whonix specific stuff.

Decide on application launcher paths.

There is tb-starter/usr/share/applications/janondisttorbrowser.desktop at master · Kicksecure/tb-starter · GitHub but that would not work when starting Tor Browser manually from its data folder ~/.tb/tor-browser.

Decide on application launcher paths.

There is tb-starter/usr/share/applications/janondisttorbrowser.desktop at master · Kicksecure/tb-starter · GitHub but that would not work when starting Tor Browser manually from its data folder ~/.tb/tor-browser.

On a second thought, it is better to add the if firejail is installed, automatically use it, otherwise skip it, stuff here:
tb-starter/usr/bin/torbrowser at master · Kicksecure/tb-starter · GitHub

(Because then it would work when starting firejail from the desktop launcher and using torbrowser from the command line. [But not when starting it from ~/tb/tor-browser.])

And perhaps an option (disabed by default) “tb_not_use_firejail_even_if_installed”.
tb-starter/etc/torbrowser.d/30_default.conf at master · Kicksecure/tb-starter · GitHub

Its better to keep the TBB apparmor profile separate from Firejail’s just in case a user wants to uninstall either one because of unforeseen bugs affecting either.

No feature request needed - what I’m looking for is a simple wrapper script that executes “sudo firecfg” creating all the symlinks for apps with a profile available. So protection is activated out of the box on Whonix. A systemd service file can probably do?

Sounds good though above my skills. Please include this whenever you can.

Too many packages, too much effort just to keep the geeks happy.

I don’t want stuff that belong into Debian in Whonix as every bit harder to see through. Especially when Debian later introduces it and then their trigger starts to conflict with Whonix trigger or so means double work.

It’s the wrong tool. Up to Debian, but I think a simple Debian packaging dpkg trigger would be the most appropriate here.

IF TBB Upstreaming of Yawning's Firejail Script (#19055) · Issues · Legacy / Trac · GitLab gets merged… OR… IF one manually uses https://git.schwanenlied.me/yawning/tor-firejail/src/master/start-tor-browser… (Which has the same effect.) Then…

  • No /usr/bin/torbrowser modifications required.
  • No /usr/share/applications/janondisttorbrowser.desktop modifications required.

Anyhow. Even if we might not need it. (And even if it might even break things later [explained below…]… I got a basic implementation of adding firejail to tb-starter /usr/bin/torbrowser done in the tb-starter firejail branch.

On a second thought that implementation will not work. All the env vars (FONTCONFIG_PATH, HOME, etc.) are not required (these are for the start-tor-browser script only.)

(You can see what it exactly tb-starter is doing by running bash -x torbrowser btw.) Essentially all that tb-starter /usr/bin/torbrowser besides other functionality such as sanity tests is doing… What matters here it is starting Tor Browser “using the command line”.

Forget about tb-starter /usr/bin/torbrowser for a moment. If you can tell me what command to run in terminal, then I can script it in tb-starter. I imagine something like this…

      /usr/bin/firejail \
         --profile=/path/to/profile \
          /home/.tb/tor-browser/Browser/start-tor-browser

Once you can tell me that, I can finish the tb-starter firejail branch.


But let’s say we had tb-starter firejail support, it might break things once TBB Upstreaming of Yawning's Firejail Script (#19055) · Issues · Legacy / Trac · GitLab got merged. Because then first /usr/bin/torbrowser would firejail it and then shortly after start-tor-browser would also firejail it. I speculate that this is a recipe for issues.

Of course tb-starter could autodetect when start-tor-browser could native firejail support and then skip tb-starter firejail therefore (grepping start-tor-browser), but things would get more and more complex and obscure.

Great. I’ll be able to say when I know the answer to this question:

This is probably the way to go because once its done you can forget about it.


I’d say it to GitHub - Kicksecure/apparmor-profile-torbrowser: AppArmor profile for The Tor Browser Bundle (TBB) - https://www.whonix.org/wiki/AppArmor - for better security (hardening).. (The clean way would be to rename the packatge to containment-profile-torbrowser but let’s skip this overhead.)

Without a custom package we won’t be able to ship custom profiles for programs that don’t necessarily have apparmor profiles but I prefer all profiles to upstream anyway rather than maintaining our own. I don’t think we will use Firejail to isolate Whonix specific daemons like sdwdate or cpfp (because systemd supports similar properties).


Its very unlikely that Debian will allow something like a firecfg post-install script to enable symlinks by default. It will be considered “intrusive” because it will do unexpected changes to other unrelated packages in a general purpose distro.

Why can’t we do this? firecfg symlinking already sorts out the mess that we would have needed to deal with hfor every package we cared about. A better option - a simple script that runs once at build time to activate firecfg is enough to ensure safe defaults while not interfering with a user’s preferences should they choose to disable firecfg symlinks for whatever reason.

Did you test https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/RelativeLink/start-tor-browser and it worked? If so, I would set the state of TBB Upstreaming of Yawning's Firejail Script (#19055) · Issues · Legacy / Trac · GitLab to needs_review. (Could still take a long time until review and merge but anyhow.)

Of course tb-starter could autodetect when start-tor-browser could native firejail support and then skip tb-starter firejail therefore (grepping start-tor-browser), but things would get more and more complex and obscure.

This is probably the way to go because once its done you can forget about it.

I hope this is right. I foresee this could be causing issues in future. (Would happen if the grep breaks in case they change their implementation in which script they add firejail.)

I’d say it to GitHub - Kicksecure/apparmor-profile-torbrowser: AppArmor profile for The Tor Browser Bundle (TBB) - https://www.whonix.org/wiki/AppArmor - for better security (hardening).. (The clean way would be to rename the packatge to containment-profile-torbrowser but let’s skip this overhead.)

Without a custom package we won’t be able to ship custom profiles for programs that don’t necessarily have apparmor profiles

In that case we create a new package, containment-profiles-xxx.

but I prefer all profiles to upstream anyway rather than maintaining our own. I don’t think we will use Firejail to isolate Whonix specific daemons like sdwdate or cpfp (because systemd supports similar properties).

Ok.

Its very unlikely that Debian will allow something like a firecfg post-install script to enable symlinks by default. It will be considered “intrusive” because it will do unexpected changes to other unrelated packages in a general purpose distro.

One day they will also enable AppArmor by default once AppArmor was installed. As per upstream feature request:

Please automatically enable AppArmor when the userspace tools are installed
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702030

I don’t think it will be different for firejail.

I want as little Whonix specific modifications to general stuff without having raised it upstream.

A better option - a simple script that runs once at build time to activate firecfg is enough

Not enough. Doesn’t work for users who upgrade. Then there will be discussions about the differences of new builds vs upgraded builds. I want to keep the number of such discrepancies as low as possible. Every issue will get raised over and over and over again it all sucks up recourses. Piles up. Until a point, where the project becomes unmanageable.

Probably also does not work for software that has profiles but where the package gets installed by the user after firejail was installed. I speculate for reasons of cleanness, it will not be creating symlinks for binaries that are not yet installed in preparation that it may one day be installed.

The only clean way to implement this is a dpkg trigger. Run firecfg - if some option is set in a .d config filder - each time something is installed to /usr/bin/, /sbin or perhaps best even / (therefore running it every time during apt-get). Otherwise it will always be inconsistent whether an installed firejail, and profile, and to be contained binary is installed at the same time will result in using firejail. That working for some users but not for all. Such things are horrible.

I can implement this dpkg trigger into the security-misc package, but raising this upstream beforehand is very much desired by me. Because whenever someone criticizes why it is done in Whonix and not a general thing, I can just reply with an ideally valid and irrefutable reasoning by posting a single link. So when I will forget about this, I don’t have to spend time again on making going through the thought process and making the argument again.

1 Like

I’ll try it soon.


You make very good points about firecfg that I can easily repost to upstream to explain why we need this.

I can implement this dpkg trigger into the security-misc package, but raising this upstream beforehand is very much desired by me. Because whenever someone criticizes why it is done in Whonix and not a general thing, I can just reply with an ideally valid and irrefutable reasoning by posting a single link. So when I will forget about this, I don’t have to spend time again on making going through the thought process and making the argument again.

OK. Trying upstream first is always the most logical place to start and then resort to custom solutions if they are stubborn.

1 Like

https://bugs.debian.org/822693#25

Update on my ticket a couple of posts back:

The proposed feature to remember custom firejail parameters in profiles will land after the next release :slight_smile:

1 Like

Gave start-tor-browser a try but unfortunately it is badly broken. It forces Iceweasel to run with a disabled Torbutton.

1 Like

Okay. So we are back to square one. I put this on hold for now from my side. First of all we need a working firejail profile for Tor Browser before distribution integration makes any sense.

This question has been researched and answered here. Please share your opinion on the conclusion:

1 Like

I agree with that. Flatpak looks nice at first superficial view to me, but we have to see if it will become popular. But even if it does, I guess it will take some years. Perhaps Debian Stretch + 1. (Which will be Debian Buster.) Looks like firejail is possible and the way to go right now.

/etc/skel/.bashrc symlink breaks firejail:
⚓ T519 /etc/skel/.bashrc symlink breaks firejail