Too many features

[netblue30]

Done so far:

• removed cgroups code
• changed --disable-firetunnel into --enable-firetunnel in configure.ac
• disabled chroot by default in /etc/firejail/firejail.config
• shell none set as default
• removed --shell=
• private-lib disabled by defautl in /etc/firejail/firejail.config

Discussed in #5183

^{Originally posted by SkewedZeppelin June 8, 2022}
The past few versions have been adding more and more arguable unnecessary features further increasing attack surface of firejail.

The best part of firejail is the collection of ready to use profiles for programs, nothing else offers this.
What ever happened to the minimal LTS version?

Can these be #ifdef'ed out?

• ids is --disable-ids
• --appimage
• --bandwidth, --netstats, --nettrace are --disable-network
• --build?
• --cpu?
• --tunnel is --disable-firetunnel

any others?

^{Originaly posted by rusty-snake June 8, 2022}

Can these be #ifdef'ed out?

While for us #ifdef works good, the most users will get their firejail binary from their package-manager. Therefore we should make sure that there are options in firejail.config to disable those features too (--appimage has one).

any others?

• --cgroup
• --shutdown
• --trace (subset of --build)
• --tracelog?

[netblue30]

And that's exactly what we are going to do! I would say for most features we'll have compile time and run time configuration. Then we need to talk what we keep in the default configuration most people are using.

[amano-kenji]

You can split privileged parts into a much smaller binary. Then, you can add more features in another binary.

[rusty-snake]

#510 and a few other places

Also #5157.

[netblue30]

You can split privileged parts into a much smaller binary. Then, you can add more features in another binary.

We've been doing it for a few years now. The files starting in "f" in /usr/lib/firejail directory (fseccomp, fcopy etc.) have been split out from SUID binary and are run in a temporary sandbox (see src/firejail/sbox.c). We even run external some programs this way - the largest one is ISC DHCP client (dhclient). I would say adding new fancy features in this moment is quite easy.

[netblue30]

Is anybody using --tracelog or --cgroup? I would take them out, I mean completely gone!

[rusty-snake]

--cgroup

Does it even work with an unified hierarchy (aka. v2)?

No, I don't think there is any relevant use.

--tracelog

It's still useful I think. Maybe we can keep libtracelog.so and make --tracelog just an alias for env LD_PRELOAD=....

[glitsj16]

Is anybody using --tracelog or --cgroup? I would take them out, I mean completely gone!

I do use tracelog quite extensively for auditing sandbox violations. IMO it's a nice tool to get a finer-grained view on what's happening in a Firejail sandbox. As such it provides valuable information in the context of creating tighter sandbox profiles.

Although I've used the cgroup option on occasion, I don't have particularly strong feelings about it personally.

BUT, and this is a general comment on this topic, I don't (fully) agree with the view that Firejail has too many features, hence a larger attack surface . Sure, we should implement a finer-grained compile/run time configuration model and have a 'reasonable' set of defaults. Cutting out pieces left and right haphazardly - in the spirit of tightening Firejail's attack surface - feels a bit awkward though. Attack surfaces will always exist and IMHO it's best to leave that up to users and their (more or less) educated guesses regarding personal threat-model(s).

Personally I always liked Firejail's more universal approach (for the lack of a better word): offering a very broad toolset and motivating users to customize the hell out of their profiles. It's very much possible I misunderstand the rationale behind this specific issue. Yet, it feels like a shift towards a more set-and-forget mindset, which I for one would deplore.

Just my two cents. I do understand this is a very complex and important issue and I do appreciate all the efforts and hard work that is continuously being done by the community to keep Firejail in the best of shapes. A big thank you to all involved. Let's take the time to think this through in the spirit of open-mindedness and collaboration worthy of its importance and future development.

[rusty-snake]

My two cents to your two cents: Firstly I fully agree with "implement[ing] a finer-grained compile/run time configuration model and have a 'reasonable' set of defaults." Secondly I think we should cut of code/feature. More precisely features that are less used, have high complexity and haven't seen any love since they were implemented.

[glitsj16]

@rusty-snake Thanks for your reply. I don't see much - if any - difference in our stance here. Underdeveloped features are indeed a sore point and I can understand if those would get dropped. Currently we have zero profiles that carry the cgroup option. Yet tracelog is part of quite a lot of profiles. Not that I would personally mind doing the work on removing it from those if it is decided to take that option out. I just happen to think it is valuable :-)

[netblue30]

OK, let's keep trackelog in, but we disable it by default in /etc/firejail/firejail.config

I have removed cgroups code, maybe we will bring it back if we ever implement the "unified" cgroups interface in the kernel.

More to come, I'll keep a list with what was done on the top item.

[WhyNotHugo]

Has there been discussion on eventually dropping blacklist in favour of a plain whitelist approach? The existence of both makes firejail quite harder to grasp, and profiles a bit tricker to read/write.

whitelist has a more hardened approach too, since it starts with a "deny all" approach, which is usually the safe way to approach things.

[kmk3]

@netblue30 commented on Jun 13:

OK, let's keep trackelog in, but we disable it by default in
/etc/firejail/firejail.config

I have removed cgroups code, maybe we will bring it back if we ever implement
the "unified" cgroups interface in the kernel.

More to come, I'll keep a list with what was done on the top item.

I don't have strong feelings on either change related to the issues below, but
please finish the ongoing removals before starting a new one:

• Remove --cgroups support #5200
• ci: Error: chroot feature is disabled in Firejail configuration file #5201

[glitsj16]

Has there been discussion on eventually dropping blacklist in favour of a plain whitelist approach?

@WhyNotHugo I don't think that's part of the discussion here. It can be awkward to get used to the difference between those options, very true. I prefer whitelisting profiles (too), but not every application can (easily) be sandboxed like that. So I guess a blacklist option (or whatever one would prefer to call it) is here to stay for the foreseeable future. Good points though. Nothing stops you from opening a separate discussion thread for it :-)

[rusty-snake]

Agreeing with @glitsj16 making blacklist/whitelist is outside of the scope of this issue an far more complex as you need to redesign both because

1. you need a way for blacklisting profile because not all programs work with whitelisting profiles.
2. there are use cases like whitelist ${DOCUMENTS} but blacklist ${DOCUMENTS}/Secret

[netblue30]

I disabled private-lib in /etc/firejail/firejail.config. Out of 1191 profiles only 70 were using it.

[rusty-snake]

private-lib is still initialized as 1, isn't it?

firejail/src/firejail/checkcfg.c

Lines 49 to 63 in db0349a

	int i;
	for (i = 0; i < CFG_MAX; i++)
	cfg_val[i] = 1; // most of them are enabled by default
	cfg_val[CFG_RESTRICTED_NETWORK] = 0; // disabled by default
	cfg_val[CFG_FORCE_NONEWPRIVS] = 0;
	cfg_val[CFG_PRIVATE_BIN_NO_LOCAL] = 0;
	cfg_val[CFG_FIREJAIL_PROMPT] = 0;
	cfg_val[CFG_DISABLE_MNT] = 0;
	cfg_val[CFG_ARP_PROBES] = DEFAULT_ARP_PROBES;
	cfg_val[CFG_XPRA_ATTACH] = 0;
	cfg_val[CFG_SECCOMP_ERROR_ACTION] = -1;
	cfg_val[CFG_BROWSER_ALLOW_DRM] = 0;
	cfg_val[CFG_ALLOW_TRAY] = 0;
	cfg_val[CFG_CHROOT] = 0;
	cfg_val[CFG_SECCOMP_LOG] = 0;

[netblue30]

Fixed, thanks!

[netblue30]

Closing it for now. Any other ideas we'll reopen it.