Re: [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

[George Dunlap <george.dunlap@citrix.com>]

On 03/27/2018 11:20 AM, George Dunlap wrote:
>>> +### Further RLIMITs
>>> +
>>> +RLIMIT_AS limits the total amount of memory; but this includes the
>>> +virtual memory which QEMU uses as a mapcache.  xen-mapcache.c already
>>> +fiddles with this; it would be straightforward to make it *set* the
>>> +rlimit to what it thinks a sensible limit is.
>>> +
>>> +Other things that would take some cleverness / changes to QEMU to
>>> +utilize due to ordering constrants:
>>> + - RLIMIT_NPROC (after uid changes to a unique uid)
>>> + - RLIMIT_NOFILES (after all necessary files are opened)
>>
>> I think there is little difficulty with RLIMIT_NPROC since our qemu
>> does not fork.  I think we can set it to a value which is currently
>> violated for the current uid ?
> 
> Well AFAICT classic POSIX allows you to set rlimits on yourself, but not
> on another process.  Since this is on the *user id* rather than the
> *process*, I didn't think "setrlimit [as root] -> exec -> setuid" would
> work correctly; I assumed you'd have to have "exec -> setuid ->
> setrlimit", which would require further changes to QEMU.
> 
> I now realize that it might be that the limit will follow the current
> uid of the process, in which case "setrlimit -> setuid" might have the
> expected behavior.  But a quick Google search shows that the interaction
> of RLIMIT_NPROC and setuid() is tricky[1][2], and may vary from
> implementation to implementation; relying on the interaction to be
> correct (and stay correct) seems somewhat risky (unless POSIX has
> explicitly documented what should happen in that case, which again a
> quick Google search hasn't turned up).
> 
> Linux does seem to have a "set rlimit on another process" system call
> (prlimit).  But that would still require at least a little bit of care,
> as then we'd need to set the limit after the setuid but before the guest
> started running.  And in any case I couldn't (again in a quick search)
> discover that FreeBSD has such a system call (and working correctly on
> FreeBSD seems to be a design goal).

Actually, it looks like RLIMIT_NPROC isn't POSIX (at least it's not
listed in [1]), but it is supported by FreeBSD [2], it would seem.  The
lack of an explicit specification for NPROC / setuid interaction makes
it doubly risky to rely on.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/
[2]
https://www.freebsd.org/cgi/man.cgi?query=setrlimit&apropos=0&sektion=2&manpath=FreeBSD+12-current&arch=default&format=html

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel