| |||||||||||||
eclone()eclone()Posted Nov 20, 2009 1:00 UTC (Fri) by socket (guest, #43)Parent article: eclone() Okay, I'm confused. I have some memory of a topic of debate in kernel-land, long ago, about PID randomization. I don't recall exactly why randomizing PIDs was considered a good idea, but I think it was somehow security-related. It seems that the proposal discussed here, "the ability to create a new process with a specific process ID," would be exactly what randomized PIDs attempts to prevent. So, I'm not sure what I'm talking about, obviously, but does this give anyone else a suggestion of what I'm talking about?
(Log in to post comments)
eclone() Posted Nov 20, 2009 9:32 UTC (Fri) by anselm (subscriber, #2796) [Link] If PIDs are increased sequentially, unrelated programs can use the rate of process creation as a »covert channel« for (low-bandwidth) communication. Randomised PIDs prevent that.
eclone() Posted Nov 20, 2009 12:28 UTC (Fri) by quotemstr (subscriber, #45331) [Link] Couldn't you use fluctuating number of processes as an even-lower-bandwidth covert channel?
eclone() Posted Nov 20, 2009 12:43 UTC (Fri) by anselm (subscriber, #2796) [Link] Maybe. Off the top of my head, the problems with that might be that
The main difference is that with sequentially numbered PIDs, the receiver of the covert channel only needs to fork(2) periodically and look at the returned child PID to find out how many processes have been created in the meantime; it does not need to be able to find out how many processes are running on the system, let alone be able to find out how many child processes another process has (when a suitably hardened system may prevent it from finding out any details about that process at all, which is why the covert channel is necessary to begin with).
eclone() Posted Nov 26, 2009 23:59 UTC (Thu) by efexis (guest, #26355) [Link]
Yeah I get what you're saying but it's all cool (at least on the proposals I looked in more detail at, I assume the case is still the same here); the process's 'real' PID will still be the same as what it always would've been if it had been fork()ed or clone()ed at that point without specifying a new PID for it. If you want to send it a kill signal or look at its memory usage in /proc/$pid, nothing will have changed there. But what you're doing with the clone() call is creating a new PID namespace, and the process is born within this namespace, and gets a new 'virtual' PID that addresses it from within there. Any other processes that also exist in that namespace will talk to the process with the new virtual PID, and cannot talk to processes that don't have a PID in that namespace. For example, each new namespace can be born with a process with PID of 1 which acts as the init (collecting child processes that live longer than their parents do etc), but to the outside world the process may have a PID of 16384 for all it matters.
Therefore any process can start up with a PID of its choosing providing you create a namespace for it and don't fill it with other stuff first. The idea here is that you can suspend a whole container(/namespace) full of processes with virtual PIDs that may be talking to each other by PID, write them out to disc, and then at a later point recreate all the processes from the image into a new container with the same virtual PIDs (but new real PIDs) and they won't need to any of the wiser.
:-)
|
|||||||||||||