Re: mlock(2) for ordinary users


On Fri, 21 Jul 2006, Peter Jeremy wrote:

Currently mlock() and munlock() are restricted to the root user - which prevents an ordinary user locking their process into RAM to the detriment of the system as a whole. Whilst this is a valid concern, there are good security reasons for allowing a user to lock small amounts of memory (a few pages) to ensure that sensitive information (private keys, passwords etc) don't wind up on swap devices.

There is a resource limit for locked pages (RLIMIT_MEMLOCK) and, despite the man page, a quick look at the code implies that it really is honoured. Could someone with more VM-foo please confirm whether the last line of the man page is still correct.

I would like to suggest that the suser() tests in mlock() and munlock() be removed and the default RLIMIT_MEMLOCK is reduced from infinity to (say) 1. The only gotcha I can see is that lots of sysctl() functions use RLIMIT_MEMLOCK via sysctl_wire_old_buffer() and vslock().

I think I'd like to see the functionality you suggest -- i.e., the ability to allocate pinned memory pages to unprivileged processes. However, I have to wonder about whether this isn't already enabled for a reason -- in particular, I have to wonder if it works at all. The whole idea of resources limits is that you bill new use to a credential, and credit reduced use to a similar credential. Probably, we're interested only in memory pinned at the request of the process, not memory pinned by the kernel on its behalf. The normal questions I'd try to answer about whether it works currently are:

- When pages become locked on behalf of a credential, is it correctly billed
to the credential?

- When pages become unlocked (or are released), are any credentials that have
requested it be locked credited?

- What happens when the credential on a process changes between when memory
is locked and unlocked?

- What happens if more than one credential requests the same page of memory be
locked and unlocked?

- Is locked memory properly credited back to the credential on process exit
and other non-explicit unmapping points?

Note in particular that more than one credential can request that the same page be locked -- if two processes map the same page from a file, or one is a fork of the other and has inheritted a shared mapping, we need to handle that "correctly". And we need to handle cases like setuid -- as with other resource limit implementations, the right credential needs to be credited. In the case of socket limits, for example, we actually keep a reference to the allocating credential in the struct socket so that when the socket is freed, we can credit the resources back to the original credential, not to the credential of whatever process last references the socket. Presumably something similar would be required here, and a quick glance doesn't suggest this is implemented.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages