mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager
synced 2024-07-09 04:05:56 +00:00
110 lines
4.7 KiB
Markdown
110 lines
4.7 KiB
Markdown
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.
|