Integration with firejail / crabjail / bubblewrap

[planetoryd]

I have posted a question in netblue30/firejail#5779 (comment)

I got one reply with OpenSnitch is just a firewall, though pretty cool, especially UI. I think THE answer would be to integrate Firejail with it (or just the UI)

I actually prefer crabjail tho https://codeberg.org/crabjail/issues/issues/1, because I am biased towards Rust, and firejail has obscure, ambiguous syntax for configuration. I often have to edit the profiles that I have no clue what they mean at all.

The integration would make it the one-stop solution for linux-sandboxing. Flatpak does too much by being both a package manager and sandbox, and it still doesn't support netns natively. For the package managing part Nix is better, preferably with IPFS.

[gustavo-iniguez-goya]

Moved to ideas. I don't think we should add this. I don't even know how we could integrate it, or what the user would expect from opensnitch in this regard.

I mean, this is an application firewall and I guess that no-one expects that it will fully isolate applications, only controls network activity. It can intercept and block connections by application, but that's all. It can be configured to intercept connections from containers, but it's not enabled by default.

On the other hand, apps like firejail control all aspects of an application, from filesystem to networking:

you can enable/disable network protocols for the isolated applications, so some functionality is already there.

[planetoryd]

no, I didn't mean that. and firejail/flatpak's network sandboxing feature is too crude

the integration is @topimiettinen 's idea, and it's just about the UI. I think there should be no problem making a UI that does both firewall and sandboxing. firejail/apparmor doesn't prompt the user for rule changes. the idea is to make it like opensnitch, and eventually put all of them in one place, because why not. basically what is missing from linux, compared to android.

[voidpointertonull]

Seems like there was quite a bit of miscommunication here mostly by not describing well what would be a rather useful feature.
After dissecting what was likely desired, it feels like it matches what I'm also looking for, so I'll describe the point I see in this, but without the generalization that likely derailed the topic.

Flatpak is an increasingly common solution for distributing programs in a sandbox with all required dependencies. Problem is that while it went the questionable way of trying to emulate phone apps with many of their limitations, it stopped even short of that, because it's not isolating networking.
The only case programs get a network namespace is when network access is disabled, otherwise they get to enjoy full access to the host's network with finer grained network isolation requests going ignored so far.

OpenSnitch could help here with some namespace awareness which seems to be lacking (that's also a security problem).
The usual Flatpak program currently has 3 namespaces: mount, pid, user. Even without going into depths of how those could be used, simply being able to make a rule to allow traffic if there's no namespace (could be one specific, not looking for all possible namespaces) would work well with the model of being trusting by default, but wanting to lock down the more questionable parts of the system which ideally reside in sandboxes/containers anyway.
This would be already quite useful, and namespace awareness should be needed for other reasons too.

The trickier part is higher level integration, but I can see that being out of scope.
For example the user might desire to have rules for the Flatpak package org.mozilla.firefox, but the lower level information according to lsns is not exactly straight-forward to identify:

        NS TYPE   NPROCS     PID USER COMMAND
4026533232 mnt        74  511014 user bwrap --args 42 firefox
4026533234 pid        74  511014 user bwrap --args 42 firefox

Regarding the need of namespace awareness and security issue, there's a problem mostly with mount namespaces.
For example Firefox showed up as /app/lib/firefox/firefox-bin in OpenSnitch which is really its path inside its container, but there's nothing indicating that being in a mount namespace. Without the distinction if I whitelist /usr/bin/ping, then the network confinement of a container that's desired to be tightly controlled could be simply escaped by using that path inside which would be highly likely allowed given that most containers have a single user.