mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4210] "Warning: cannot find /var/run/utmp" but looks for "/dev/null/utmp" instead #2580
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#2580
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 @donob4n on GitHub (Apr 24, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4210
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
@smitsohu commented on GitHub (May 2, 2021):
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
fs_var.c@smitsohu commented on GitHub (May 2, 2021):
We should certainly update the warning so there is no mismatch with the actually checked path.
@smitsohu commented on GitHub (May 2, 2021):
A cursory search reveals there is a package utmps-openrc, but I'm not clear about the default utmp path
@donob4n commented on GitHub (May 12, 2021):
Thanks for checking but since alpine removed firejail package due enforcing policy against suid files I will close this issue.
@smitsohu commented on GitHub (May 16, 2021):
Error was fixed in
ef4b0de190@kmk3 commented on GitHub (May 16, 2021):
@donob4n commented 4 days ago:
That's unfortunate; AFAIK it can be built without being SUID. Links from
Alpine for reference:
for inclusion in Alpine"
@rusty-snake commented on GitHub (May 16, 2021):
There is a
./configure --disable-suid. Anyway you need tochmod u+slater by hand. See #1846. (Related: #4273)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
force-nonewprivs yesinfirejail.configis a good mitigation and can be set by distributors too. But in the end it depends on the threat model.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 https://github.com/netblue30/firejail/pull/3849#issuecomment-752230829 #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.
@kmk3 commented on GitHub (May 22, 2021):
@rusty-snake Thanks for the very detailed response (and thanks @donob4n for
bringing it up). I plan on creating a thread later to better understand what
happened (and to avoid spamming in here) and possibly come up with action
items. Are GitHub Discussions adequate for potentially long threads or should
it just be an issue?