Thanks for the quick feedback, I appreciate it. Privileges needed by ocserv-main - Any chance the up/down scripts could be moved to ocserv-sm? Based on the other thread, I think the answer is no due to concurrency constraints, but figured I would check.
Limiting NET_ADMIN capability - If the goal is to permit unconstrained execution of up/down scripts in ocserv-main, then stripping capabilities from it is probably a no-go as well. Fuzzing IPC - Will take a stab at this. Seems like the protobuf serializer is fairly mature, so will concentrate on the payload. Pkcs11 - HSM seems like the right approach, even if it is a bit heavyweight. Primarily the threat we wanted to mitigate is off-line attacks against the key, but I think we might be able to mitigate that using Azure Key Vault for offline storage (i.e. script to pull down the keys at container startup and store them in a volatile filesystem location). -----Original Message----- From: Nikos Mavrogiannopoulos <[email protected]> Sent: Monday, February 3, 2020 7:09 AM To: [email protected] Cc: Alan Jowett <[email protected]> Subject: [EXTERNAL] OCserv hardening > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fgnutls%2Fgnutls%2Fissues%2F594&data=02%7C01%7CAlan.Jowett%40microsoft.com%7C77e7a95069bf4bbd6e5708d7a8b2baa0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163357896036411&sdata=URWPIoHttmA1YJk904x3L4EGd4tIlPnGR7P1HxOlDA0%3D&reserved=0 _______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
