"Warning: cannot find /var/run/utmp" but looks for "/dev/null/utmp" instead #4210
Comments
This is musl, which doesn't support utmp out of the box. The question is if Alpine has or you have a utmp file somewhere in the system, possibly in a non-default location. If there is no utmp file, it is safe to just ignore the warning. If there is a utmp file, and in a stable location, we can add the path to |
|
We should certainly update the warning so there is no mismatch with the actually checked path. |
A cursory search reveals there is a package utmps-openrc, but I'm not clear about the default utmp path |
|
Thanks for checking but since alpine removed firejail package due enforcing policy against suid files I will close this issue. |
|
Error was fixed in ef4b0de |
|
@donob4n commented 4 days ago:
That's unfortunate; AFAIK it can be built without being SUID. Links from |
There is a
Well, if you look at the security records of firefox or linux ... Comparing the number of CVEs is IMHO not a good fact base. (Although the point raised is not entirely unjustified).
What kind of broken? According to my observation, the most profiles (especially those of much used software (= much tested)) work fine (if you use the latest firejail version ¹). "Broken things" like restricted file system access is intentional. ¹ if a program gets an update that requires an adjustment of it's profile, end-users get this fix with the next firejail-release which can take month. That's something to improve.
Setting For single-user desktops a user-to-root exploit which requires that an attacker can execute any command as user is rather harmless. A spyware does not need to be root to get the passwords you enter in firefox. Your important documents/pictures/videos can be encrypted by ransomware with user right. Yes, as root it could encrypt your full disk, that's annoying, but you can reinstall your OS. And being part of a botnet work with user right too. For multi-user systems (where users do not (fully) trust each other) a user-to-root(-to-other-user) is one of the worst things you can thing off. And for servers there are better sandboxing solutions (systemd's native features for example, https://gist.github.com/rusty-snake/c6d773fc27ddde9071461e0fe4010610). TBH a real world damage by firejail is unlikely as it is installed on to few systems. A malware targeting the mass of users would exploit systemd/the kernel/... to get root, against a targeted attack by a highly skilled attacker you are helpless anyway (or your system is unuseable). And the biggest security hole is still sitting in front of the computer. Update: Some discussion on firejail's security #3046 #3849 (comment) #3527 #3082.
Always work but never finish 😉 . That's an never ending task.
Sad but that's the way it is.
👍
I follow the development of bubblejail since I discovered it and it is the best alternative to firejail I know. It currently does not have the development power in the background like firejail and far less profiles (7 and one generic). Therefore you need to write the most profiles for the programs you use by yourself, however it has a somewat declarative syntax (firejail's syntax is more imperative) and a GUI. Personally (as GNOME user) I don't like the Qt-GUI, but that is a matter of personal preference. In addition it has support for xdg-dbus-proxy and uses libseccomp. That's what makes it an alternative to firejail in contrast to self-hacked bubblewrap wrappers that come up in every "firejail is insecure" discussion. |
|
@rusty-snake Thanks for the very detailed response (and thanks @donob4n for |
Hi I'm running firejail on Alpinelinux and see this warning in almost all apps that I try to run.
I took a look at source and noticed that in 'fs_var.c':
The value of UTMP_FILE is
/dev/null/utmpEnvironment
Alpinelinux Edge
firejail version 0.9.64.4
debug output
The text was updated successfully, but these errors were encountered: