jane413/meta-distro
Watch
1
0
Code Issues 12 Projects Packages Wiki Activity Actions

sandboxing: design-notes #9

New issue
Open
opened 2026-07-27 03:10:57 +02:00 by jane413 · 0 comments
jane413 commented 2026-07-27 03:10:57 +02:00
Owner
Copy link

https://pad.gnome.org/cJEvNbuQRN2WpN3iQLlhhA#BTO-7---Flatpak-v2-Topic

  • reusing flathub manifest would be perfect for sandboxing based upon apk-tools, maybe some automagic conversion tool?

networking

There are three types of networking usecases really simplified (hopefully):

  • physical hardware <=> interface
  • interface <=> vpn <=> interface
  • interface <=> application

The daemons operating on physical hardware/vpns may require communication with other services. (iwd with ofono, modemmanager with geoclue and vowifi).

There are a bunch of different ways to approach this problem. I suggest a netns based one, the main drawback being that it's really important to not loopback packets in this setup. Careful routing tables should help with this, another approach maybe tagging the traffic and then filter it out (BPF?).

Special care needs to be taken with applications which expect to configure their own firewalls. docker/podman, firewalld/ufw, wg-quick/other calling nft/iptables directly.

Existing networking daemons: networkmanager, systemd-networkd.
systemd-resolved can probably be spawned per namespace.

In general it can't be assumed that applications know how to handle /etc/netns/self/{resolv.conf, hosts}, so overmounting is required -> integration into systemd-run/bubblewrap is needed?

https://pad.gnome.org/cJEvNbuQRN2WpN3iQLlhhA#BTO-7---Flatpak-v2-Topic - reusing flathub manifest would be perfect for sandboxing based upon apk-tools, maybe some automagic conversion tool? # networking There are three types of networking usecases really simplified (hopefully): - physical hardware <=> interface - interface <=> vpn <=> interface - interface <=> application The daemons operating on physical hardware/vpns may require communication with other services. (iwd with ofono, modemmanager with geoclue and vowifi). There are a bunch of different ways to approach this problem. I suggest a netns based one, the main drawback being that it's really important to not loopback packets in this setup. Careful routing tables should help with this, another approach maybe tagging the traffic and then filter it out (BPF?). Special care needs to be taken with applications which expect to configure their own firewalls. `docker/podman`, `firewalld/ufw`, `wg-quick/other calling nft/iptables directly`. Existing networking daemons: `networkmanager`, `systemd-networkd`. `systemd-resolved` can probably be spawned per namespace. In general it can't be assumed that applications know how to handle /etc/netns/self/{resolv.conf, hosts}, so overmounting is required -> integration into systemd-run/bubblewrap is needed?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
No results found.
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jane413/meta-distro#9
No description provided.