Bug and expected behavior
surf browser from suckless doesn't startsurf browser from suckless startsNo profile or disabling firejail
firejail --noprofile PROGRAM in a shell?whereis PROGRAM, firejail --list, stat $programpath)?firejail calls surf from /usr/local/bin instead of /usr/bin/Reproduce
Steps to reproduce the behavior:
firejail surf> surf
Reading profile /etc/firejail/surf.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Warning: networking feature is disabled in Firejail configuration file
Parent pid 204257, child pid 204258
Warning fcopy: skipping /etc/alternatives/view.de.1.gz, cannot find inode
Warning fcopy: skipping /etc/alternatives/vi.ja.1.gz, cannot find inode
Warning fcopy: skipping /etc/alternatives/wine.fr.1.gz, cannot find inode
Warning fcopy: skipping /etc/alternatives/faked.es.1.gz, cannot find inode
Warning fcopy: skipping /etc/alternatives/ex.de.1.gz, cannot find inode
Error fcopy: size limit of 500 MB reached
Warning: skipping crypto-policies for private /etc
Warning: skipping pki for private /etc
Private /etc installed in 32.50 ms
15 programs installed in 22.44 ms
Blacklist violations are logged to syslog
Child process initialized in 136.45 ms
dbus[28]: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to open "/var/lib/dbus/machine-id": No such file or directory; Failed to open "/etc/machine-id": No such file or directory)
D-Bus not built with -rdynamic so unable to print a backtrace
Parent is shutting down, bye...
Environment
lsb_release -a)Distributor ID: Debian
Description: Debian GNU/Linux bullseye/sid
Release: testing
Codename: bullseye
firejail --version) exclusive or used git commit (git rev-parse HEAD)> firejail --version
firejail version 0.9.62
Compile time support:
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- file and directory whitelisting support is enabled
- file transfer support is enabled
- firetunnel support is enabled
- networking support is enabled
- overlayfs support is enabled
- private-home support is enabled
- seccomp-bpf support is enabled
- user namespace support is enabled
- X11 sandboxing support is enabled
Additional context
Other context about the problem like related errors to understand the problem.
None required.
Checklist
find / -name 'firejail' 2>/dev/null/fd firejail to locate profiles ie in /usr/local/etc/firejail/PROGRAM.profile)What changed calling the program by path=without firejail (check whereis PROGRAM, firejail --list, stat $programpath)?
firejail calls surf from /usr/local/bin instead of /usr/bin/
Why is firejail started when you run /usr/bin/surf?
Can you try firejail --private-etc=machine-id surf.
/usr/bin/surf 'google.com' workssurf 'google.com' doesn't because /usr/local/bin/surf via firejail is calledfirejail --private-etc=machine-id surf 'google.com' works@hyiltiz you can simply add d1dd363 to your surf.profile.
Why did that fix the issue and how could've known better to fix it myself? I see that it reported Failed to open "/var/lib/dbus/machine-id" but I wasn't sure if that was a side-effect of some other issue, or can just be fixed directly. Why would a browser need my machine-id in the first place?
Why did that fix the issue and how could've known better to fix it myself? I see that it reported Failed to open "/var/lib/dbus/machine-id" but I wasn't sure if that was a side-effect of some other issue, or can just be fixed directly.
That's not easy to answer in a few sentences, but I'll try. Generally speaking, the more you familiarize yourself with all the firejail options, the Linux filesystem layout etc., the better your chances become to detect potential issues in sandbox profiles. Logging output is key, which implies starting applications from terminal, which not all users do or are willing to do. As you know, security is always a matter of degrees, certainties are urban myths at best.
In this particular case, seeing the failure to open /var/lib/dbus/machine-id is one clue that D-Bus was involved in breaking surf. Another clue is present in the filesystem, as that path is symlinked to /etc/machine-id. Finally, seeing that the surf.profile limits access to /etc via the private-etc option, a trained and experienced collaborator as @rusty-snake can put these pieces of information together quickly and suggest a fix.
Like with so many things in life, the more you put yourself into this 'behind-the-scenes' position, the easier it gets. Practice helps in other words. Give it a try, most if not all information is out there. Fine-tuning firejail profiles to your own particular workflow is almost always possible (via the .local override files).
Why would a browser need my machine-id in the first place?
Now that's a very good question indeed. It seems to be related to having access to the audio layer. If you don't need audio in the surf web browser, it's possible to add firejail's machine-id option to a surf.local file to harden things a bit. That generates a new, random id inside the sandbox, which does break audio support, but keeps the browser functioning otherwise.
Let's hope this brief attempt to answer your questions enables you to improve your firejail sandboxing skills, regards!
Why would a browser need my machine-id in the first place?
Access to /etc/machine-id (see man 5 machine-id for more info) is needed for PulseAudio and sometimes DBus (depending on compiler-flags?).
Most helpful comment
That's not easy to answer in a few sentences, but I'll try. Generally speaking, the more you familiarize yourself with all the firejail options, the Linux filesystem layout etc., the better your chances become to detect potential issues in sandbox profiles. Logging output is key, which implies starting applications from terminal, which not all users do or are willing to do. As you know, security is always a matter of degrees, certainties are urban myths at best.
In this particular case, seeing the failure to open /var/lib/dbus/machine-id is one clue that D-Bus was involved in breaking surf. Another clue is present in the filesystem, as that path is symlinked to /etc/machine-id. Finally, seeing that the surf.profile limits access to /etc via the private-etc option, a trained and experienced collaborator as @rusty-snake can put these pieces of information together quickly and suggest a fix.
Like with so many things in life, the more you put yourself into this 'behind-the-scenes' position, the easier it gets. Practice helps in other words. Give it a try, most if not all information is out there. Fine-tuning firejail profiles to your own particular workflow is almost always possible (via the .local override files).
Now that's a very good question indeed. It seems to be related to having access to the audio layer. If you don't need audio in the surf web browser, it's possible to add firejail's
machine-idoption to a surf.local file to harden things a bit. That generates a new, random id inside the sandbox, which does break audio support, but keeps the browser functioning otherwise.Let's hope this brief attempt to answer your questions enables you to improve your firejail sandboxing skills, regards!