Split-off from audit bug 1173749:

 ## d) UNIX Doman Socket Peer PID Retrieved via `SO_PEERCRED` is Subject to Race Condition

 One major security property of `spice-vdagentd` is that it only allows those
 clients access to most of the SPICE features (like clipboard, file transfer)
 that are currently in an active session according to systemd (see also section
 2.b). It is possible for arbitrary local users (like *nobody*) to connect to
 `spice-vdagentd` but these connections should not be able to interact with the
 host machine, because they don't belong to the active session.

 The session check is performed after a new UNIX domain socket connection is
 established in `agent_connect()` in `vdagentd.c:937`. The check basically
 relies on these two source code lines:

 ```
 pid = vdagent_connection_get_peer_pid(VDAGENT_CONNECTION(conn), &err);
 agent_data->session = session_info_session_for_pid(session_info, pid);
 ```

 The peer's PID is obtained via glib's `g_socket_get_credentials` which boils
 down to the `SO_PEERCRED` socket option that is supported for UNIX domain
 sockets (see `man 7 socket`, `man 7 unix`, `struct ucred`). The man page says
 about this:

 > The returned credentials are those that were in effect at the time of the call
 > to connect(2) or socketpair(2).

 This means that there is a race condition between the point in time when a
 client performs the `connect()` call to establish a connection with
 `spice-vdagentd` and the time `spice-vdagentd` retrieves and checks the PID in
 its `agent_connect()` function. The PID in question can already have been
 replaced by an unrelated process. Therefore the session that `spice-vdagentd`
 associates with this PID might be a different one than the actual peer process
 belonged to, when the `connect()` system call was performed.

 An attack to exploit the race condition requires the following steps:

 1. an attacker can inherit a UNIX domain socket file descriptor to a child
 process that performs the `connect()` to `spice-vdagentd` and exits
 immediately again, thereby freeing the PID (let's call it the malicious PID)
 in the system as soon as the parent process performs a `wait()` on the exited
 child process. This malicious PID will now be associated in the kernel with
 the `SO_PEERCRED` data returned for the connected UNIX domain socket.
 2. now the attacker needs to perform a PID cycle in the system (i.e.
 create many useless child processes to cause the maximum PID - typically 32768 -
 to be reached in the system and new processes get assigned small PIDs
 again). When the PIDs assigned by the kernel are getting close to the
 malicious PID, the attacker needs to stop creating child processes and wait
 for unrelated processes from other users to come into existence.
 3. Once the malicious PID gets reassigned to an unrelated process and the
 `agent_connect()` function runs in `spice-vdagentd`, it will retrieve wrong
 session information for the existing connection. If the malicious PID gets
 reassigned to a process running in the active session, then the connection
 that the attacker uses will get access to the SPICE features and can
 communicate with the host, although the attacker would otherwise not have
 sufficient privileges to do so.

 The described race condition is very hard to hit under normal circumstances,
 because step 2., the PID cycle, is taking a long time and the
 `agent_connect()` function in `spice-vdagentd` is very likely to run before an
 unrelated process gets reassigned the malicious PID in question. When combined with
 the file descriptor exhaustion security issue described in section 3.c,
 however, then this attack will become way more feasible.

 This combined attack works like follows:

 - Exhaust all file descriptors in `spice-vdagentd` as described in section
   3.c.
 - Now perform the attack steps 1. and 2. as described previously. What
   happens now is that the attacker's UNIX domain socket `connect()` will succeed,
   because on kernel level this is still possible. `spice-vdagentd` won't be able
   to `accept()` this connection, though, because no more file descriptors are
   available to do so. The connection remains pending on the listening socket,
   however.
 - Now for step 3., once the attacker notices that the malicious PID got
   assigned to an unrelated process, he can stop the file descriptor exhaustion
   put into place previously, thus making it possible for `spice-vdagentd` to
   `accept()` the malicious connection pending in the kernel. Only now will the
   `agent_connect()` function run, and it will more reliably determine the
   wrong session for the connection.

 ### Impact

 1. A compromised local account with little privileges inside the virtual
   machine like *nobody* can try to become the "active agent" for
   `spice-vdagentd` for the graphical session of a legitimate local user. If
   successful then the attacker can access the host's clipboard contents or
   send malicious clipboard content to the host. The attacker can also retrieve
   file data from the host (compare section 2.b) or send invalid screen
   resolution and display information to the host.
 2. The combined attack using the file descriptor exhaustion and the
   `SO_PEERCRED` race condition is still not 100 % reliable but it can be
   repeated many times to increase chances of success. The only unpredictable
   ingredient is victim child processes appearing that get assigned the desired
   malicious PID and stay around for long enough for `spice-vdagentd` to pick up the
   wrong session information.
 3. If the victim's graphical session already runs a legitimate `spice-vdagent`
   then a successful attack will trigger an information leak protection logic
   in `vdagentd.c:874`. This has the effect of a denial-of-service, because
   neither the attacker nor the legitimate user will be able to use the SPICE
   features anymore.
 4. If the victim's graphical session is not running a `spice-vdagent` then the
   attacker can achieve all the effects described in 1.
 5. If 3. applies (the victim's is already running `spice-vdagent`) then the
   attacker could try to crash the currently running `spice-vdagentd` (see
   section 3.c for a possible attack vector). systemd should then restart the
   `spice-vdagentd` while the victim's `spice-vdagent` should exit but not be
   restarted. After this situation 4) applies.