> Quick question for folks on this list. > During our security review of OpenConnect server, a couple of the question were raised: > 1) Can we drop privileges from the ocserv-main process after forking the ocserv-sm? > a. Looking through the code, I don't see any obvious reason why not, but I might be missing something. I am not sure if there were other (minor) reasons but if remember well the main reason for privileges in the main server is to be able to run the up/down scripts with no constraints. > 2) Assuming the use of Docker, would it make sense to split ocserv-sm into its own process chain so that it can run in separate docker container (i.e. not have it fork from ocserv-main)? > a. Goal is to avoid having to grant NET_ADMIN cap to a service that is internet facing (i.e. ocserv-main and ocserv-worker would not have NET_ADMIN cap). Seems like a good idea, but there is quite some state that may be overlapping between the processes and communication will not be that straightforward. I was thinking that an selinux policy for ocserv could address your concern above about ocserv-main confinment but under a container that may not work that well. > 3) Has there been any work done to fuzz the IPC, especially from ocserv-worker -> ocserv-sm? > a. My team has a task to do this, but if we already have data on this that would be a great place to start. Not really, but having that would be great! > 4) What is the recommended best practice for protecting the X509 cert private key? > a. TPM + password? Encrypted disk partition? My vision in gnutls was to make pkcs11 transparent so that you can use an HSM (hard or soft) to protect the private key. I'm not aware of any secure (as in isolated) softhsms but there are plenty in hardware, and TPM (1 or 2) can be seen as one. For TPM2 support you may want to rely on a PKCS#11 front-end, as existing TPM2 tools do not have the necessary capabilities to allow a user of gnutls to use their output transparently [0]. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/issues/594 _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
