On Tue, 14 Feb 2023 12:51:22 +0100 Michal Privoznik <mprivozn@xxxxxxxxxx> 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
