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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel