mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5190] Too many features #2909
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2909
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @netblue30 on GitHub (Jun 10, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5190
Done so far:
Discussed in https://github.com/netblue30/firejail/discussions/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?
any others?
Originaly posted by rusty-snake June 8, 2022
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).
@netblue30 commented on GitHub (Jun 10, 2022):
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 commented on GitHub (Jun 10, 2022):
You can split privileged parts into a much smaller binary. Then, you can add more features in another binary.
@rusty-snake commented on GitHub (Jun 11, 2022):
#510 and a few other places
Also #5157.
@netblue30 commented on GitHub (Jun 12, 2022):
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 commented on GitHub (Jun 12, 2022):
Is anybody using --tracelog or --cgroup? I would take them out, I mean completely gone!
@rusty-snake commented on GitHub (Jun 12, 2022):
Does it even work with an unified hierarchy (aka. v2)?
No, I don't think there is any relevant use.
It's still useful I think. Maybe we can keep libtracelog.so and make --tracelog just an alias for
env LD_PRELOAD=....@ghost commented on GitHub (Jun 12, 2022):
I do use
tracelogquite 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
cgroupoption on occasion, I don't have particularly strong feelings about it personally.BUT, and this is a
generalcomment 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
universalapproach (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 moreset-and-forgetmindset, 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 commented on GitHub (Jun 12, 2022):
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.
@ghost commented on GitHub (Jun 12, 2022):
@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
cgroupoption. Yettracelogis 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 commented on GitHub (Jun 13, 2022):
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 commented on GitHub (Jun 14, 2022):
Has there been discussion on eventually dropping
blacklistin favour of a plainwhitelistapproach? The existence of both makes firejail quite harder to grasp, and profiles a bit tricker to read/write.whitelisthas a more hardened approach too, since it starts with a "deny all" approach, which is usually the safe way to approach things.@kmk3 commented on GitHub (Jun 14, 2022):
@netblue30 commented on Jun 13:
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:
@ghost commented on GitHub (Jun 15, 2022):
@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
blacklistoption (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 commented on GitHub (Jun 15, 2022):
Agreeing with @glitsj16 making
blacklist/whitelistis outside of the scope of this issue an far more complex as you need to redesign both becausewhitelist ${DOCUMENTS}butblacklist ${DOCUMENTS}/Secret@netblue30 commented on GitHub (Jun 23, 2022):
I disabled private-lib in /etc/firejail/firejail.config. Out of 1191 profiles only 70 were using it.
@rusty-snake commented on GitHub (Jun 23, 2022):
private-lib is still initialized as
1, isn't it?db0349a5ec/src/firejail/checkcfg.c (L49-L63)@netblue30 commented on GitHub (Jun 23, 2022):
Fixed, thanks!
@netblue30 commented on GitHub (Aug 29, 2022):
Closing it for now. Any other ideas we'll reopen it.