dwmw2 at infradead.org
Sat Jul 28 04:06:48 PDT 2012
On Sat, 2012-07-28 at 12:56 +0200, Stef Walter wrote:
> Think users moving, deleting the file, or unmounting, and all sorts of
I'm thinking of exactly that. If I delete the file or unmount the
removable or encrypted file system on which it resides, the system MUST
NOT be able to connect to the VPN any more. That's probably *why* I
deleted or unmounted it. If you tell the security folks "actually it's
OK, we squirrelled away a copy of the key so that we can connect
automatically in future and it's stored in some new storage that you
haven't vetted for security"... they're going to have a fit.
I'm also, as I said, thinking of the case where I *overwrite* the key
with a new one, because the old one is about to expire.
> Then start thinking about all the various formats that
> certificates can be in. We support tons of import certificate formats
> in Gcr. That makes sense for an importer. Should openconnect support
> all those formats? Nope.
Yes, it already has to. The command line tool is never going to ditch
support for using keys from files, and go to *only* PKCS#11.
That's why I've just added support for interpreting the old horrid
OpenSSL encrypted PEM files, even when using GnuTLS. Etc.
> In addition openconnect will be often running in a different security
> context. Due to SELinux, NFS homedirs, and all sorts of other things
> it can't reliably read locations like the home directory where the
> user has write access.
In fact, when invoked through NetworkManager the authentication part
(which uses the cert) *is* running in the user's own session. We make
the *connection* as root, using a cookie which is obtained from a
We have to support *both* modes of operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6171 bytes
Desc: not available
More information about the p11-glue