mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1639] Chroot -- /etc/resolv.conf file as symlink being rejected #1103
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#1103
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 @nuxwin on GitHub (Nov 9, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1639
@netblue30
Tested with version 0.9.50.1 from the 0.9.50-bugfixes branch.
When installing the resolvconf package under Debian 9/Stretch, the /etc/resolv.conf file is a symlink pointing to /etc/resolvconf/run/resolv.conf and /etc/resolvconf/run is a symlink pointing to the /run/resolvconf directory. In short, the real resolv.conf file
is a dynamic (volatile) file which real path is /run/resolvconf/resolv.conf:
For our project, we are creating a chroot and of course, our chroot is containing identical layout for the resolv.conf file:
Problem is that firejail reject the /etc/resolv.conf file:
Well, this is due to the following check in fs.c file
Environment
@nuxwin commented on GitHub (Nov 9, 2017):
@netblue30
Also, with dev-master, another error is raised in place:
I saw that you added some fixes lately regarding the /etc/resolv.conf file but now we end with an false error:
As you can see in my quotes above, that is totally false. I'm wonder why you're doing so many checks on the resolv.conf file. All that checks make your life harder and instead of improving security, you're breaking the whole chroot feature. A check on file owner and permission (not world-writable) should be sufficient here. The /etc/resolv.conf file can be dynamic (that is far most case now) and therefore is a symlink in most cases.
@Ferroin commented on GitHub (Nov 9, 2017):
If
/etc/resolv.confisn't world readable on your system, then something is not behaving correctly. At least glibc, and I'm pretty sure uClibc and whatever musl uses for networking functions, need that file readable to resolve hostnames properly when configured to use DNS. Most other DNS resolver libraries need it too. That requirement is why it's so important. If somebody spoofs the file in some way, they have functionally full control of what systems you talk to on the network, and can potentially trick you into thinking your external hostname is something else.That said, the file should not be world-writable, as that would make such spoofing absolutely trivial.
@nuxwin commented on GitHub (Nov 9, 2017):
@Ferroin
Sorry, you're right. It is world-readable and MUST be world-readable. I wanted say not world-writable ;) I'll edit my previous post.
@netblue30 commented on GitHub (Nov 10, 2017):
The logic is broken. There should be no checking on /etc/resolv.conf, the file is replaced anyway by firejail with the real /etc/resolv.conf. I put a fix in
ac0d75f943@nuxwin commented on GitHub (Nov 12, 2017):
@netblue30
Thanks ;) I'll checkout and give a try soon ;)