Separate (some) user applications from the operating system

Development
21

Probably relevant if we do eventually create a Wayland proxy:

1 Like
22

Hi,
The idea is really great in my opinion, but any kind of sand boxing is a complex subject to any entry-level user, although necessary to avoid APTs. We should make it easy out of the box.

The problem I see is having to restart or lose user sessions in order to access the untrusted-user.

I don’t know if it’s possible or maybe is kind of per-application sandboxing. But I think the best would be to be able to run the unstrusted-user without having to close the user session. Like run the untrusted-user into the user environment but with so limited access, with independent home folder.

Just imagine you are using the main user, you have multiple apps opened, you are in a video call and you need to open a secured browser for access some websites you don’t really trust at all. Be able to run the browser or any other app in the user session but with the untrusted-user permissions, and the application only with access to the /home/untrusted-user/ but not to /home/user/.

Something like:
Log in in the unstrusted-user, download different applications, like the browser or any other close source app (unsecured), like discord/spotify, fill a list of installed apps with the path of them.
And later onto the user session, execute something like open-untrusted-user and after that a list of applications able to run with untrusted-user.

——————————
Select the application you want to run with low permissions
——————————
1. Browser → source of the bin with the permissions of unstrusted-user
2. Spotify → source of the bin with the permissions of unstrusted-user
……

The unstrusted-user don’t have permissions to read or write in the user’s folders or daemons, like happen with the sysmaint user

I hope I have explained myself well; it’s difficult for me.

23

Agreed. Introducing yet another boot mode with a new user type would be a bad user experience, and while we had to introduce a new boot mode to make the sysmaint privilege level safe, I don’t think we’ll need to do that here. My hope is to have the sandbox application provide a UX similar to a virtualization app like VirtualBox. It can then allow applications in the sandbox to run side-by-side with applications in other sandboxes and unsandboxed applications.

I like your explanation a lot :slight_smile: I think the UX will hopefully be even better than the already good suggestion you have here. Ideally one should be able to open the sandboxer application, click on a sandbox they’ve created, open a terminal in the sandbox, and run sudo apt install whatever, installing the new application into the sandbox. Or, if the user has installed a GUI package manager like Synaptic into the sandbox, they can click a sandbox, click to open Synaptic, find the app they want, and install it that way. Then they wouldn’t need to log out even to install applications.

We’ll probably draw inspiration from Qubes OS for this, since the idea above is essentially “Qubes OS, but minus a lot of the more complicated features, and implemented using containerization rather than VMs”. It won’t be nearly as feature-rich as Qubes at least to start with, and it won’t be able to match Qubes in terms of security, but for users who don’t use Qubes, or for users who want better security within an individual Qube, it should still help a lot.

2 Likes
24

I was going to say something like that with UI, but I figured that would be a lot of work.

But that was the idea I had in my mind, a sandboxer application where you could install other apps and run them into the main user, but with a sanboxing at user level, not application level as other sanboxers do and we know aren’t secure and optimous at all. Like termux in Android, is like a sandboxed terminal that run into an app but without root permissions

We should find something intermediate between good security, good performance and user friendly. I don’t use qubeos for the overhead it have, is actually difficult to use it in a low resource pc (in my opinion).

If this feature is implemented I would use it for example for close source applications that I use daily, like Discord, and I don’t trust anything. Don’t allow discord to access my files and daemons/bus of my main user, etc. It would be great

1 Like
25

Over the last few days, I’ve been spending a lot of time designing (not yet coding, just designing) the sandboxing framework, using the notes above as a roadmap. Sharing the whole design here would be rather cumbersome (and the design is quickly evolving and is subject to change or overhaul at any moment), but a quick summary is:

  • We have tentatively settled on systemd-nspawn as the underlying sandboxing framework. It is sufficiently feature-rich to do what we need to the best of our knowledge.
  • We have a user interface somewhat mapped out. The UI design is heavily inspired by VirtualBox, and treats individual sandboxes as VM-like instances that can be powered on and off.
  • Unfortunately, it looks like we’re going to have to run the core sandboxing engine as root. systemd-nspawn is non-functional under Qubes OS when run as a non-root user (apparently the Qubes kernel is missing a feature required to get unprivileged systemd-nspawn to work), and even outside of Qubes, I have not been able to get it to work unprivileged. Other unprivileged sandboxing frameworks use SUID executables to hack around the parts of sandboxing under Linux that require root privileges, so getting them to work without SUID would be, to say the least, quite difficult. The only engine we know of that could be used for that is Podman, and Podman simply does not seem to be designed to be used the way we intend on using containers (it could be used, but it would be unintuitive, difficult, and would “mess up” the Podman user interface for anyone who had a use for Podman other than using our sandboxing framework). It would also complicate file, folder, and device sharing, all of which are essential features.
  • For now, validating proxies are being mostly skipped. It was a fun idea, but it will be very difficult to implement and maintain. In the short term, we may simply allow sandboxed apps to connect directly to Wayland and Pipewire. Longer term (or possibly now, if warranted), we may add a feature that allows a sandbox to run its own Wayland compositor, which can then be VNC’d to from the host, thus providing a good level of isolation without the complexity of a validating proxy. Something similar might be possible for audio, though this is unclear. We may end up with something similar to a validating proxy for console access.

More details will be forthcoming once we have a design that looks solid enough to start implementing (which may still be a while, this is going to be a rather complex system no matter what we do, so we need to get the design right the first time if we want to avoid major refactoring headaches later).

1 Like
26

The design is still far from finished, but it’s getting there. Those who are interested can look at the current state of the design here:

(EDIT: Previously the design was in a Github gist here: Work-in-progress sandbox-manager-dist design ¡ GitHub, however it has now been moved into the Git repo for sandbox-manager-dist.)

2 Likes
27

Well I must say that is a long read but will the “sandbox-manager” be able to achieve installing packages/apps per user instead of globally for all users?

GUI screen design looks nice and the overall layout you have provided in this gist is nice if u get my gist :slight_smile:

One thing though about systemd-nspawn and --network-veth part as mentioned…

Wouldn’t VPN’s like in the case of having more then one VPN app benefit from a networknamespace? Only reason I ask is I have had DNS Configuration Conflicts (/etc/resolv.conf) when switching between ProtonVPN and MullvadVPN before for a stated example.

Also what issues could arise with user Firewalls? Could host firewall rules (iptables/nftables) not apply correctly to container traffic because the traffic appears to originate from the host itself? No mention of integrating with host firewalls or conflicts user specific firewalls?

28

Yes, each user account will have its own set of sandboxes separate from other sets, and apps will be installed in those individual sandboxes.

VPNs within sandboxes isn’t really a use case I had in mind. It’s a good edge case to think about though, and since our goal is to provide something vaguely Android-like and Android has VPN apps, I’d say it’s in scope. I doubt it will be possible to adjust the host’s firewall from within the sandbox since adjusting the firewall is a root-only operation (I think) and the sandbox doesn’t have root privileges outside of its user namespace, so for VPN apps to work in a sandbox at all, a network namespace would probably be required. (That way the per-namespace firewall can be configured however the sandbox wants.) The VPN would only apply to applications inside the sandbox.

nftables firewalls are per-namespace according to some pages I looked up. For instance, the Arch Wiki describes using a network namespace to contain Docker’s firewall changes. See:

2 Likes
29

It will be quite a while before there’s a functional prototype to look at, but development of sandbox-manager-dist itself has started:

2 Likes