Re: [PATCH 4/4] qemu_passt: Don't let passt fork off

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 14 Feb 2023 12:51:22 +0100
Michal Privoznik <mprivozn@redhat.com> wrote:

> When passt starts it tries to do some security measures to
> restrict itself. For instance, it creates its own namespaces,
> umounts basically everything, drops capabilities, forks off to
> further restrict itself (the child is where all interesting work
> takes place now). This is sound, except it's causing two
> problems:
> 
> 1) the PID file FD, which we leak into the passt process, gets
>    closed (and thus our virPidFile*() helpers see unlocked PID
>    file, which makes them think the process is gone),

I didn't realise this was the case, but giving passt write (unless I'm
missing something) access to a file created by libvirtd doesn't look
desirable to me.

> 2) the PID file no longer reflects true PID of the process.
> 
> Worse, the child calls setsid() so we can't even kill the whole
> process group. I mean, we can but it won't be any good.
> 
> Fortunately, passt has '--foreground' argument, which causes it
> to undergo the same security measures but without forking off the
> child.

They're not the same -- unfortunately they can't be, because, on Linux,
you can't change the PID of an existing process, so there's no way to
enter a new PID namespace without clone().

If passt remains in the same PID namespace, it's still able to see PIDs
of other processes, which is not desirable from a security perspective.

Again from a security perspective, this is probably a small impact, so
I guess it's fine if there's no other way around it. But I see a lot of
ways around it...

-- 
Stefano