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

From: Ian Jackson <ian.jackson@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
Date: Tue, 27 Mar 2018 15:36:36 +0100	[thread overview]
Message-ID: <23226.22260.207702.968821@mariner.uk.xensource.com> (raw)
In-Reply-To: <1a845c55-df25-1754-3e14-bdc47e658da8@citrix.com>

George Dunlap writes ("Re: [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans"):
> On 03/27/2018 02:33 PM, Ian Jackson wrote:
> > Anyway IMO we should set RLIMIT_NPROC after fork and before execve.
> > If this causes setuid to fail in qemu, qemu will crash.  But this
> > could only be the case if the new uid already has other processes,
> > which it shouldn't do.  (If it does, the new uid is probably
> > contaminated by a previous domain with the same domid.)
> 
> I was more worried about the limit not having the expected effect after
> the setuid().

I think we can safely rule that out.

> > I could find nothing in SuS explaining when process A may send signals
> > to process B.  So I resorted to the BSD manpages:
> > 
> >   https://www.unix.com/man-page/freebsd/2/kill/
> > 
> >   For a process to have permission to send a signal to a process
> >   designated by pid, the user must be the super-user, or the real or
> >   saved user ID of the receiving process must match the real or
> >   effective user ID of the sending process.
> 
> The text of both the FreeBSD and Linux man pages looks to be copied
> verbatim from [1].
> 
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html

I don't know how I missed that.  It's the 2nd paragraph!

> > `pet' could be a uid associated with a reserved domid, eg dom0.
> 
> Right -- it looks like that could work.  I hadn't initially noticed the
> {RUID, SUID} => {RUID, EUID} distinction.
> 
> It's kind of hard to believe this is so difficult to pull off.

Yes!

> Should we post this to that forum, for the benefit of other people who
> end up finding the same discussion? :-)

Tempting.  Let's wait until we see if it works, first ...

Ian.

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