On Mon, Feb 3, 2020 at 4:58 PM Alan Jowett <Alan.Jowett@xxxxxxxxxxxxx> wrote: > > 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. I do not remember if there is a limiting factor there though I'm not sure it is a good idea (but feel free to change my mind especially with a clean patch/design :). If I remember well my main concern was to have a simple security module to make it easy to audit and avoid secret leaks. That's why any async logic and libev/scripts was not used there. > 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. Removing privileges from the main process would have some benefits, irrespective of containers. The problems that I saw at the time of design was that adding a new process for up/down scripts looked like an overkill, and I didn't want to overcomplicate the security module. However, if the (up/down and route) scripts are not used, it could be that the main process can drop and switch to an unprivileged user. I have never tested whether that would work actually, but from a very quick glimpse I do not see an obvious reason for not to. > 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). If you really want to protect them outside the container you may want to experiment with pkcs11 forwarding as well: https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html However I have not used it in practice for anything but smart cards, so the performance hit, is unknown to me. regards, Nikos _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
