On 07/03/2021 19:44, Gert Doering wrote:
Hi,On Sun, Mar 07, 2021 at 01:36:03PM -0500, Selva Nair wrote:"I'm not sure", TBH. rlimit handling in unix is a bit of an unknown territory for me. What I understand is that root can *increment* the rlimit at will, but I'd assume that the rlimit value "in existance right now" (specifically, the soft limit) applies to root processes as well. Sort of a voluntary protection against processes running away.On modern linux kernels (since some 2.6.x..) RLIMIT_MEMLOCK applies only to unprivileged processes -- privileged processes allowed to lock "unlimited" amount of memory as documented in man mlock. We updated the man page based on that sometime ago.Indeed, "man mlock" says something about "privileged processes" on Linux (it doesn't say that on FreeBSD).We could also consider using setrlimit to increase the limit before dropping privileges.That's another possible angle... just up soft+hard to "something" (how much would that be? :-) ) and log the fact. David, Arne, any opinion on this? Where do we want to go?
I do think mlock serves a purpose in ensuring where memory pages are kept, from a general perspective. But does it really make sense in today's virtualized world? Where we're mostly having several GiBs of RAM available. I'm not sure it matters that much either way. But for those who care about memory security, it is a useful feature.
Since the code to enable this shouldn't be enormous (since we use mlockall()), I don't see much winning in code complexity by tearing it out when it may provide some security related features.
The unprivileged vs privileged process on Linux kernels change happened in 2.6.9, according to "Linux Programming Interface" (LPI) [Michael Kerrisk, chapter 50)]. I do not consider that an issue at all; I can't think of any still fully supported Linux distributions with such an ancient Linux kernel. It should really not run security related tasks (from a general perspective).
If I've understood the LPI book correctly, the default (RLIMIT_MEMLOCK) is set to 32KiB for both hard and soft limits. Clearly not enough for our use case.
setrlimit() by itself isn't really that magical. Basically you populate struct rlimit with the limits you want and call setrlimit(RLIMIT_MEMLOCK, &new_limits); Plus error checking and all that.
But we should look into if we should acquire CAP_IPC_LOCK capability as well, otherwise we need to completely ensure that mlockall() is really called before privileges have been dropped. I know I had to kick out --mlock on a few configs a long while ago, related to lack of privileges - but that could have been SELinux restrictions as well. Need to revisit this.
-- kind regards, David Sommerseth OpenVPN Inc
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
