https://bugs.kde.org/show_bug.cgi?id=424068
Bug ID: 424068
Summary: NetworkManager does not clean up certificates
Product: plasma-nm
Version: 5.19.3
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jgrul...@redhat.com
Reporter: gm...@ratijas.tk
Target Milestone: ---
SUMMARY
Orphan keys and certificates are not cleaned up.
STEPS TO REPRODUCE
1. Add OpenVPN connection
2. Remove connection added in step 1.
3. Check the directory
`$HOME/.local/share/networkmanagement/certificates/$connection`
OBSERVED RESULT
Keys and certificates which are no longer needed are still there.
EXPECTED RESULT
Clean up relevant files under
$HOME/.local/share/networkmanagement/certificates/$connection when removing a
connection.
SOFTWARE/OS VERSIONS
> Arch Linux, KDE/Plasma
> lib32-libnm-glib 1.18.5dev+12+ga8746f48ca-1
> libnm 1.24.2-1
> libnm-glib 1.18.5dev+12+ga8746f48ca-1
> networkmanager 1.24.2-1
ADDITIONAL INFORMATION
There are incompatibilities with NetworkManager and GNOME that arise from using
custom
re-implementation of `nmcli`. People are working on it here:
https://bugs.kde.org/show_bug.cgi?id=396530. In the meantime, we might attempt
to fix
the issue with plasma-nm's implementation ourselves.
Originally posted at GNOME GitLab:
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/53.
Original issue text:
=== ratijas:
Using:
* NetworkManager as in Connections — System Settings Module.
* OpenVPN plugin for NetworkManager as in this repository.
# Problem
During import of *.ovpn profile via "+" -> "Import VPN connection..." this
plugin parses its content, stores recognized options somewhere and _extracts
inline keys & certificates_ into files under
`$HOME/.local/share/networkmanagement/certificates/$connection`. Upon removal
via corresponding "-", leftover files are left intact, thus polluting the
directory and leaking credentials.
# Solution
Clean up relevant files under
`$HOME/.local/share/networkmanagement/certificates/$connection` when removing a
connection.
=== ratijas:
I acknowledge it may be more of an issue with NetworkManager itself, but it
might need integrations steps from openvpn plugin as well.
=== Thomas Haller:
when a profile gets deleted, NetworkManager doesn't know whether the referenced
files are still relevant to the user. How would it? Hence, it does not delete
them.
While this should be improved, it's not clear how exactly.
Do you think NetworkManager should always delete all referenced files when
deleting a profile? That doesn't seem desirable, and dangerous.
Yes, files have severe downsides, that's why we would better use a certificate
store and PKCS#11 URLs.
=== ratijas:
It creates them itself — Of course it is in charge of deleting them!
It knows exactly that files are managed by NetworkManager himself because
referenced files are stored inside special directory which I mentioned twice in
the original post.
> That doesn't seem desirable, and dangerous.
Danger is leaving sensitive data behind and misleading user into believing that
it was cleared. Moreover, When I recreated network with the same name but
different profile, it might create different set of files (e.g.:
`tls-crypt.key` instead of `tls-auth.key` except that the former is not
supported at the moment #54 (closed)) leading to clashes and overlaps.
Now that I think about it, naming connections based on their display name is
not good enough. Consider using UUID instead. (Should I open separate issue?)
**Removing to trash** might be a better options, if it can be implemented in
reasonably compatible cross-platform way. Seems like freedesktop.org has a
standard or two on this matter.
> PKCS#11 URLs
Never heard of those. I am not an expert in this field. Looks promising.
=== Thomas Haller:
> It creates them itself
NetworkManager didn't create them. When you do nmcli connection import or
click import in nm-connection-editor (or gnome-control-center), then those
tools create the file.
You could also create the very same profile without using import. Just have the
files on disk, and set the paths accordingly.
NetworkManager doesn't know how the profile was created, or what the user wants
to do with the certificate files when deleting the profile.
=== ratijas:
Well then, if there is an import, then there must be 'unimport'.
In general — "that's why we can't have nice things" on Linux: no integration
whatsoever. Or as the proverb says, "*left hand doesn't know what the right
hand is doing*". :(
I won't go much into technical details, but whenever there is a **set up**,
there will be a need for **tear down**. If there is no such concept in mncli at
the moment, then *maybe* it should be introduced.
But then again, as a user, I don't care much for how it is implemented. As an
open source developer though, I *might* get involved and contribute, but don't
rely on my words any time soon.
=== ratijas:
I've played around with `nmcli` and `nm-connection-editor`. To no surprise,
both are doing exactly same thing. KDE/Plasma's plasma-nm applet is slightly
different, but people are working on a fix:
https://bugs.kde.org/show_bug.cgi?id=396530.
So, `nmcli` has two commands I am interested in: `import` and `delete`. Just
like with plasma-nm's "+" -> "Import" and "Delete", they are **not
complementary** commands.
> Not to mention, both tools export my ovpn profile as heavily modified with
> externally linked files (instead of in-line keys and certificates).
The only major difference though is the storage for extracted credentials:
- plasma-nm stores files
`$HOME/.local/share/networkmanagement/certificates/$connection/{{ca,cert}.crt,{private,tls-auth}.key}`
- `nmcli` imports into `$HOME/.cert/nm-openvpn/$connection-$cred.pem`
Neither tool cleans up credentials upon deletion / removal of a connection, and
I think it should be fixed. Now that we know two managed locations, we just
have to check that other connection entries do not refer to the same
keys/certificates, and if not — remove orphans to trash.
I will proceed to duplicate this issue at https://bugs.kde.org for plasma-nm.
Binary `nmcli`, on the other hand, belongs to NetworkManager package on
ArchLinux, so I assume this is still the correct place to talk about it.
--
You are receiving this mail because:
You are watching all bug changes.
