Sandboxing of NetworkManager Daemon

NetworkManager runs as root user, although it might also be possible to run as a separate user (#843).

The daemon requires certain permissions to perform its tasks, but it also runs network facing code (like the DHCP library). We should better sandbox the process to mitigate exploitable bugs.

We want to drop unrequired Capabilities and confine the daemon with SELinux. The SELinux policy is maintained on downstream distributions.

For dropping capabilities, we use Systemd's CapabilityBoundingSet.

Another idea would be to run network facing code (DHCP) as a separate sandboxed process or to rewrite in a safe(er) language. Both is high effort and not clear to be worth it. Possibly that effort would be better spent in fuzzing and improved unit testing of the code.

Certificate Files

For 802-1x and VPN plugins, the connection profile can contain files. Files are highly problematic because they might be owned by a different user or not have the right SELinx context (~/.cert/). Also, they make the profile not self-contained and are hard to cleanup when deleting the file.

NetworkManager itself does not much with certificate files, mostly they are just passed on to wpa_supplicant or the VPN plugin. Wpa_supplicant in turn is not yet sandboxed (that is a problem?!), and can usually read the files (by having CAP_DAC_OVERRIDE).

One aim is to drop CAP_DAC_OVERRIDE capability. So let's focus on that. But there are similar other problems with files.

Possible Solutions:

NetworkManager mostly read the certificate files to determine whether a secret is needed. We could just pass them on to supplicant, and supplicant needs a way to call back and request more secrets. That is how VPN plugins work.
move away from files and use PKCS#11 URIs and have a certificate store.
for simple questions like is-file-valid-certificate or is-passwd-valid we could ask nm-priv-helper via D-Bus. The problem is that such requests would be asynchronous and currently the code expects an answer right away. But even a higher privileged service like nm-priv-helper might be confined by SELinux or the file might be on a fuse filesystem. Files just don't work well.
drop CAP_DAC_OVERRIDE and expect users either to not use 802-1x with certificates, to have the certificates with suitable permissions, or to grant CAP_DAC_OVERRIDE to NetworkManager.service. We do the same already w.r.t. the SELinux context.
document that users can drop CAP_DAC_OVERRIDE themselves (insecure by default), if they either don't use 802-1x certificates or make sure that the file permissions are suitable.

See @8021x_tls test for reproducing a problem.

VPN Plugins

The NetworkManager process spawns the VPN plugins, that means the plugins inherit all sandboxing from the daemon. That is a problem, because we don't necessarily know what capabilities the VPN plugin will require and we tend to just have capabilities because a VPN plugin might use it.

The solution is to let somebody else (with elevated privileges) spawn the plugins.

This could be done by running the VPN plugins a separate systemd service. That would be great, but has two severe downsides: it would only work with systemd and break non-systemd use cases. More importantly, all existing plugins need to be update for this new way of running. That could be done, however, there will be a transitioning period during which we would need both ways to run the plugin. This means there is a need to implement a systemd-less approach, and once we implement that, the incentive for using systemd decreased. It still could be done maybe in the future.

The better way is to have our own VPN plugin runner. That could be nm-priv-helper.service. It already runs as a separate service with distinct environment and sandboxing. Note that spawning the VPN plugin process is already an async operation. So replacing that with an async call to nm-priv-helper will be relatively straight forward.

Can we Drop a Capability?

`CAP_DAC_OVERRIDE`:

Used for VPN Plugins. See there for how to solve that.
Used for 802-1x certificate files. See there for how to solve that.

Other systemd Sandboxing Options

Enable sandboxing options possible. Again, the main problem are certificate files in802-1x and VPN plugins.

Enable them one at a time, and open issues/merge-request for discussion.

4.7 KiB Raw Blame History