On Tue, 2016-01-26 at 10:01 +0100, Matthias Berndt wrote: > > > > OTOH if she is keeping her cert deliberately secure on an encrypted USB > > storage device, and it gets copied to the unencrypted hard drive, she > > might not be able to connect tomorrow because she's been *fired* for > > this breach of security policy.
> What kind of security policy requires you to encrypt your USB drives > but not your hard drive? That seems contrived to me. Besides, we > already copy certificates if they are stored as blobs inside the > .ovpn file - I think it's better to be consistent here. Arguably a daft one. But I've seen stupider :) It does even make a little bit of sense, if the most sensitive item on the computer in question *is* the VPN certificate (perhaps it's used *purely* for accessing web apps and there's no local storage of anything sensitive at all — or local storage *is* carefully managed by other means, and you blindly copying a cert to where *you* choose does not fit in with that solution. Fundamentally though, the principle is simple: You *don't* copy sensitive data from where it originally resides. Whoever created the OpenVPN blob already had a choice of whether to pass the certificate by value (embedded in the blob) or by reference (a filename or PKCS#11 URI). In the latter case, where they have chosen to pass it by reference, it seems entirely wrong to take a *copy* instead of just abiding by their choice. > > And if her cert expires and she renews it, even if she is still > > employed, she's going to get very confused when NM is still using the > > *old* certificate that she's *deleted* from the USB stick and replaced > > with a new one. > Either she is technical enough to generate her own keys and > certificates, in that case it'll be trivial for her to update her > NetworkManager settings accordingly. Or she's not, in which case her > administrator will give her a USB stick with the new configuration > and she'll import it just as she did before. I think that from a > "normal user" pov, copying is definitely what I'd expect. I certainly > did. In my case, we have scripts which talk to the corporate PKI infrastructure and obtain a certificate; placing it in a known location. We configure our VPN to use the certificate from there, and definitely *not* to use a copy of it. Then when the certificate is renewed, the VPN keeps working. Unless NetworkManager did something daft and took a *copy*... > > If you do this, make it *optional* and make it clear that you're doing > > it. > How to do that? Actually, I take it back. It's *already* optional, as I noted above. If the blob contains it by value, then by all means store it where you like. If the blob has a *reference* to an existing file or PKCS#11 URI, then do not copy it ever. > > And in fact, do *not* import it to a file elsewhere; import it into > > gnome-keyring and refer to it by its PKCS#11 URI. > > Yeah, except she may well not be using gnome. We might be able to > come up with something based on the freedesktop secret service api, > I'll look into it. Yeah. Import it into "the default writeable token". Which might even be an NSS database ~/.pki/nssdb. I don't think the secret service API is relevant here; this is all through PKCS#11 and managed by p11-kit. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
