mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3026] Configuring network interface with DHCP #1898
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#1898
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 @kris7t on GitHub (Nov 4, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3026
I am using the network isolation feature of firejail with a network bridge managed by libvirt (
virbr0), so I can set up networking for sandboxes similarly to virtual machines. While firejail can auto-assign an IPv4 address by ARP scanning for a free address, there is no such feature for IPv6. Moreover, I would like to avoid clashes between sandboxed and (powered-off) virtual machines, so I would like to let the DHCP server (dnsmasq) managed by libvirt to handle address allocation of my sandboxes. (While I could assign an address manually to each and every sandbox, that would be much more error prone. I prefer to do manual assignments in one place in the libvirt config by MAC address.)I set up DHCP for IPv4 (from a /24 block) and stateful DHCP6 for IPv6 (from a /112 prefix) in libvirt. I was experimenting with running
dhcpcdin a--noprofilesandbox (in a real setup, ansbox_runcall during sandbox initialization would probably replacesudoand--noprofile, but I didn't get that far) as follows:I get the same message even if I mount
tmpfsto/var/lib/dhcp, or when I run thefirejailcommand as root.If there a way to auto-configure networking inside the sandbox by DHCP? Are there any security implications I should be aware of?
@netblue30 commented on GitHub (Nov 6, 2019):
This is a bug, thanks. It works fine for ISC DHCP client (isc-dhcp-client package on debian). You do need to start the sandbox as root in order to run the client. You would start the client as "dhclient -v eth0".
/var/lib/dhcp is used by isc-dhcp-client. Apparently dhcpcd uses /var/lib/dhclient, try a --tmpfs=/var/lib/dhclient. For /var/lib/dhcp we mount by default a tmpfs on top of it. I'll try to bring in a fix.
@kris7t commented on GitHub (Nov 6, 2019):
Thanks!
(Sorry if this derails a bit, or I maybe should open a new issue, but: ) Is there any chance I could do DHCP without running the container as root? I guess the main difficulty is that the client has to run while the sandbox is active (I can't just acquire an IP calling a DHCP client once in
sandbox_if_up, because the lease may run out).@netblue30 commented on GitHub (Nov 8, 2019):
OK, seems to be a dhcpcd problem with the way they detect the ethernet interfaces, but idc-dhcp-client works fine.
No, you need to be root to run a DHCP client. I'll add support for dhcp client support directly in the sandbox. At startup, the sandbox is root, so it should be able to run a client this way. I'll mark it as an enhancement for now.
@kris7t commented on GitHub (Nov 8, 2019):
Thanks for the pointers! I was playing around a bit with this:
Looks like
dhclienton its own won't work with a read-only/etc, because it tries to create a newresolv.conf. As a workaround,dhclient-scriptcan be modified to skip hostname and DNS resolver setting, and we can rely on the DNS servers passed tofirejailon the command line. Furthermore, thedhclientprocesses must be killed before the sandbox can cleanly shut down.I still have some wonkyness regarding IPv6 forwarding, but I suspect that's because I am doing a very evil thing (stateful NAT66).