[PATCH 4/4] qemu_passt: Don't let passt fork off
Stefano Brivio
sbrivio at redhat.com
Tue Feb 14 13:02:53 UTC 2023
On Tue, 14 Feb 2023 12:51:22 +0100
Michal Privoznik <mprivozn at 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
More information about the libvir-list
mailing list