add restrict-namespaces to (almost) all applicable profiles

[smitsohu]

Closes #5440

My algorithm was roughly as follows:

1. skip profiles with # Redirect tag
2. skip profiles without any seccomp directive
3. comment out restrict-namespaces if seccomp is commented out
4. comment out restrict-namespaces if there is a seccomp !chroot directive, indicating use of a new user namespace
5. add restrict-namespaces to all other profiles, including default.profile and server.profile

There are a few special cases, among them: basilisk.profile, palemoon.profile, fdns.profile, unbound.profile.

I didn't attempt for now to fit restrict-namespaces to common browsers.

[netblue30]

Cool!

[glitsj16]

Excellent work!

I didn't attempt for now to fit restrict-namespaces to common browsers.

The relationship in web browsers between (1) user namespaces / their internal sandbox functionality and (2) Firejail's own sandbox always interested me. It also almost always evades me. Got lots of learning to do, but @rusty-snake and I touched on this topic just recently. Looking forward to doing some comparisons running Firefox with different sets of restrict-namespaces=foo. It would be nice if we could provide a wiki page on this exotic topic in the future, offering advice on how to go about setting things up and potential security pitfalls. But we'll have plenty of time to come back to this now that restrict-namespaces is in the profiles!

[smitsohu]

@glitsj16

I think I introduced a bug in ping-hardened.inc.profile. From the calling ping.profile:

# Add the next line to your ping.local if your kernel allows unprivileged userns clone.
#include ping-hardened.inc.profile

Somehow I cannot find this hardened ping or its source code, do you still have a sample at hand (I noticed you contributed the profile), or could you maybe point me to the right place? That would be awesome.

What I would like to know is if restrict-namespaces net,user is sufficient to make it work, or if we need to comment out restrict-namespaces altogether.

[glitsj16]

@smitsohu I indeed contributed that extra include option. But there's no special version or any custom software package involved. At the time I simply noticed that there's a considerable difference in behaviour of ping on Arch Linux (my main OS) versus Debian/Ubuntu (which I happen to use in a dual-boot setup). When I first noticed the comments in ping.profile about it needing several options to be relaxed, that triggered my curiousity. The situation hasn't changed, I retested yesterday when I saw your comment.

On Ubuntu I still cannot include ping-hardened.inc.profile. It keeps breaking ping there so the comments are still valid.

On Arch Linux ping still works fine with restrict-namespaces in ping-hardened.inc.profile.
I didn't notice anything different between using restrict-namespaces and restrict-namespaces net,user, both work. Which of these is the more restrictive?

$ pacman -Q iputils
iputils 20221126-1

$ cat /etc/firejail/ping.local
# Firejail profile for ping
# Persistent local customizations

# hardened-malloc (blacklisted by globals.local)
noblacklist /usr/lib/libhardened_malloc.so
env LD_PRELOAD=/usr/lib/libhardened_malloc.so

## system-wide profile
#+ overrides

# Add the next line to your ping.local if your kernel allows unprivileged userns clone.
include ping-hardened.inc.profile

protocol unix,inet
ignore protocol

private-bin ping
private-etc alternatives,ca-certificates,crypto-policies,hosts,nsswitch.conf,pki,resolv.conf,ssl
# hardened-malloc
private-lib libhardened_malloc.so

[rusty-snake]

https://github.com/netblue30/firejail/blob/master/etc/profile-m-z/ping-hardened.inc.profile

[smitsohu]

@glitsj16 Thank you! Then we can leave it as is. Just restrict-namespaces implies all supported namespaces, so it is the more restrictive one.

[glitsj16]

@smitsohu Very welcome. And thank you for comfirming restrict-namespaces is the most restrictive in this context. With your work now fully available I think 0.9.72 will be a great release. Take care!