diff options
author | Thomas Haller <thaller@redhat.com> | 2022-03-22 13:07:46 +0100 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2022-03-28 18:04:18 +0200 |
commit | 321b59e84bf74233c043bfa58e7e4f78c6308580 (patch) | |
tree | b6d6979a40a5ee1fb8a6d9c1c2dad05ec429e6f5 /docs | |
parent | aba3401df015a2b46e632d82544f776f601cca84 (diff) | |
download | NetworkManager-321b59e84bf74233c043bfa58e7e4f78c6308580.tar.gz |
docs: add "sandboxing.md"
Diffstat (limited to 'docs')
-rw-r--r-- | docs/sandboxing.md | 109 |
1 files changed, 109 insertions, 0 deletions
diff --git a/docs/sandboxing.md b/docs/sandboxing.md new file mode 100644 index 0000000000..4e1d859aa7 --- /dev/null +++ b/docs/sandboxing.md @@ -0,0 +1,109 @@ +Sandboxing of NetworkManager Daemon +=================================== + +NetworkManager runs as root user, although it might also be possible to run +as a separate user ([#843](https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/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. + +See also [#71](https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/71). + + +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](https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/998) +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`: + +1) Used for [VPN Plugins](#vpn-plugins). + See there for how to solve that. + +2) Used for 802-1x [certificate files](#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. |