firejail / seccomp / More Options for Program Containment

Firejail:

Guide for creating profiles: Firejail Seccomp Guide | l3net – a layer 3 networking blog

Firejail is a SUID security sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.

Firejail can sandbox any type of processes: servers, graphical applications, and even user login sessions. Written in C with virtually no dependencies, it should work on any Linux computer with a 3.x kernel version.

Good:

  • No dependencies
  • Aims for ease of use. Allows wrapping anything in seccomp easily even if it doesn’t natively support it. Profile creation and debugging are easier to grasp than even apparmor.
  • Doesn’t conflict with Apparmor/ MACs and can be combined.
  • Not just limited to browsers. Profiles can be for arbitrary programs.
  • Chroot on steroids.

Bad:

  • Not in Debian repos - probably a deal breaker
  • Profiles can break with updates to software, depends on kernel version. That’s the same for Apparmor I believe. Requires maintenance with time.

I think it would be great to have something like this in Debian. I hope the authors can be persuaded to make a repo and make reproducible builds for it. What is your opinion on adding third party repos should they have one?


Firefox is working hard on rolling out seccomp support for their browser on Linux. It is developed but they are yet to enable it by default. Progress can be tracked here:

https://wiki.mozilla.org/Security/Sandbox

Looks interesting!

I think it would be great to have something like this in Debian.
I am not sure of the status, but there is an ITP: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777671 - https://ftp-master.debian.org/new/firejail_0.9.22-1.html
What is your opinion on adding third party repos should they have one?
- same hassle as if The Tor Project's repository is down or has outdated keys - gives the third party the complete ability to compromise the whole distribution - same hassle as with Whonix's repository (to [not] enable it by default; having a wizard to let users change this) - needs trustworthiness and long time commitment

[hr]

grsecurity kernel installation instructions:
https://phabricator.whonix.org/T203

firejail is now in Debian stretch:

And there is a Tor Browser firejail profile:
https://git.schwanenlied.me/yawning/tor-firejail

Firejail Dev account:

Firetools - a gui for firejail. Request packaging for Debian repos:

Use Guides:
https://wiki.archlinux.org/index.php/Firejail

1 Like

Firejail dev:

1 Like

I asked about how firejail handle isolation for X-server.

Firejail dev:

We are still working on it: Implement X11 isolation · Issue #57 · netblue30/firejail · GitHub

1 Like

systemd SystemCallFilter= containment option seccomp hardening:
⚓ T362 systemd SystemCallFilter= containment option seccomp hardening

Firejail includes many profiles by default for some common applications. A lot of the software we ship is already covered now like iceweasel, icedove, vlc, hexchat and many others. Here are their profiles:

Instead of doing any changes to our apparmor profile pakages, I propose the creation of a whonix-firejail package that would contain any custom profile created by team members until they are upstreamed to the firejail project.

Instead of doing any changes to our apparmor profile pakages, I propose the creation of a whonix-firejail package that would contain any custom profile created by team members until they are upstreamed to the firejail project.

Then it would be an install all of them vs non of them thing. But it’s
okay with me. We’d still need a maintainer to create such profiles since
I guess it’s non-trivial work, non-negligible time effort and not free
of issues. Not sure if @troubadour already has too much on its plate to
create yet another batch of profiles.

But ‘presumably’ the profiles are only going to get tighter, not looser.

Is that really different than any other package?

Further testing here reveals the software isn’t ready for prime time. Despite ‘firejail --net=eth0 -ip=10.152.152.111 qbittorrent’ no network activity was observed 2 out of 3 goes.

Hate to be a downer on my own “hey, this is out there”, but if I’m the first one to call for such containerization, there can’t be a crying need for it out there - IMO whonix resources are probably better spent elsewhere.

However, the topic of containerization, value, and heft, in a whonix context, does seem a worthy topic to keep an eye on.

Regardless of the mechanism used, e.g. docker in single application mode seems like an equally likely candidate, vs LXC full OS turnkeys - the idea of user chosen optional ‘safe app kiosk install’ seems to have merit.

If you turn the concept around, one could also see a series of ‘whonix-apps’. e.g. A whonix container installable in any system (if, e.g., a docker image), blessed as being a whonix approved anonymous (anonymizing & scrubbed/ing) turnkeyed app window.

My guess is such would be useful within qubes as well, but I expect qubes has its own equivalent mechanism already.

LXC, cgroups, ip netns, docker, vboxes, et all, seem to have come a long way. The common concepts and intents behind them seem to have many ongoing candidate implementation methodologies at various stages of development.

If I was the first to ask about firejail, … is such really all that popular a desire worthy of allocation of whonix resources?
(Says the guy that made the original request of consideration.)

need a maintainer to create such profiles since I guess it’s non-trivial work, non-negligible time effort and not free
of issues.

Profiles are really simple, so I don’t think that’s a huge burden - BUT: that makes the assumption of familiarity of containerization/LXC, etc.

I am not, so, for example, I have no idea of the pros / cons / appropriateness of the ‘seccomp’ profile directive.

In testing, I disabled a ‘noroot’ directive - aside from the LXC concepts, one would be trusting, on a per app basis, whether ‘noroot’ or not is dangerous / suitable (in a whonix context) - and for that one would have to be very familiar with the particular app, and probably its internals.

e.g. One might ask, does ‘kmail’ need ‘noroot’ not specified, or not. One might reasonably ask, why would it need root? I expect the only one who could reasonably answer such a question is one familiar with kmail internals - and there quite probably aren’t a great deal of such around. [I expect the biggest reason for noroot is apps place files in far too many unusual/unexpected places, and noroot is expedient for getting an app to run without fully understanding all the places that must be black/white-listed, exceeding the bound of the container in the process. Or at least the container being larger than it should / needs to be.] And such an app expert would be needed per app. And there are several dozen apps in there already.

One thing I noticed with my testing of ktorrent, is D-Bus use and forking apps are problematic for firejail. If whonix is by design a KDE install, and firejail is KDE broken … I came to the conclusion of hurry up and wait for further firejail maturity before looking at it any more deeply.

At least until they can demonstrate that ‘firejail --no-profile --net=eth0 {any candidate kde app}’ “just works.” (–no-profile = no restrictions, --net=eth0 = containerized network stack). i.e. To the user, ‘myapp’ and ‘firejail myapp’ should present identically without further user intervention. (Things can be made tighter, but at its loosest, it should be transparent to the user as to which way it’s running.) Seamless / transparent user use is not the case today, and it may be prudent to wait until it is.

depends on kernel version

This refers to a time when seccomp was being baked into Linux.

Your comparison is not really accurate. Read the Firejail FAQ that answers this question: https://firejail.wordpress.com/support/frequently-asked-questions/

Summary: Firejail and its supporting tools are geared towards the desktop usability and building security profiles while Docker/LXC is built for virtualization and resource partitioning on servers.

Firejail is also getting attention from the security community and has been audited recently:

Please report the problems you run into with Firejail profiles to the devs so they are corrected by the time Debian Stretch stabilizes.

Firejail workflow usability enhancement:

Ticket accepted :slight_smile:

EDIT:

Ticket implemeted!

1 Like

Ticket accepted.

1 Like

EDIT:

Feature already exists under --no-sound option.

Xpra gui isolation support landed in git and documented here:

https://forums.whonix.org/t/looking-for-firejail-seccomp-maintainer-for-better-security/2211

subgraph’s seccomp profiles:
https://github.com/subgraph/oz/tree/master/profiles

Apparently these are not compatibly with firejail?

source:
https://secure-os.org/pipermail/desktops/2016-March/000102.html

Apparently these are not compatibly with firejail?

Not compatible because different profile sematics/programming language for each. For things like whitelisted seccomp syscalls it is simple enough to read them from one profile and add them for the same program under Firejail profile.

Could we have firejail and oz both installed at the same time? Will firejail and oz be compatible as long as they do not try to confine the same application? And what happens if firejail and oz try to confine the same application?

Did someone test oz on Debian yet?

Firejail 9.40 released with X11 isolation support, file transfer capability and much more.


1 Like
1 Like