From: jfh@greenber.austin.ibm.com (John F Haugh II)
Subject: Re: process numbers
Date: Sat, 9 Jan 1993 22:24:58 GMT
Organization: AIX Software Support, Austin, Republica de Tejas

In article <C0EB6D.174w@austin.ibm.com> dcm@codesmith.austin.ibm.com (Craig Miller - dcm@austin.ibm.com) writes:
>In article <1h6hv0INNrsl@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>>
>>In article <BzMqs8.1Krz@austin.ibm.com> curt@ekhadafi.austin.ibm.com
>>(Curt Finch 903 2F021 curt@aixwiz.austin.ibm.com 512-838-2806) writes:
>>>
>>> My understanding is that it was done for security reasons.
>>
>>This is nonsense.
>
>	Uh, wait a minute Charles...  Many moons ago during the
>	early development days of AIX, there was a rumor circulating
>	around AIX development that generating sequential pids was
>	a security hole.  I think the phrase used was "covert channel".

Craig wins the prize.

The process ID is a covert storage channel.  If AIX used sequential
pids two co-operating processes could pass information back and forth
to each other with the following little piece of code -


	send_one_bit ()
	{
		int	i;

		for (i = 0;i < 100;i++)
			if (fork () > 0)
				continue;
			else
				exit (0);

		sleep (1);
	}

	send_zero_bit ()
	{
		sleep (1);
	}

	receive_bit ()
	{
		if ((first_pid = fork ()) == 0)
			exit (0);

		sleep (1);

		if ((second_pid = fork ()) == 0)
			exit (0);

		return (second_pid - first_pid >= 100);
	}

Throw some signal analysis and error correcting code in there and you
have your basic covert channel.  You could even use start and stop bits
and decode the data like it was coming in over an RS-232 line at 1 baud ...

>	Perhaps that has changed since, but saying that anything
>	Curt says is "nonsense" is going a bit overboard, don't you
>	think?  He was in AIX development back then.  Were you?

Probably not ;-), but then I was in the department that actually dreamed
that one up.  Curt isn't saying anything nonsensical ...

>>The process number is the process table index shifted 8 bits, plus a
>>number which is incremented every time a process is put in that slot.
>
>	True.  But this doesn't prove that Curt's statement is wrong.
>	AIX still doesn't generate sequential pids.

Actually, you can still play games with covert channels using the program
I typed in above.  This time, add the lines

	first_pid &= 0xff;
	second_pid &= 0xff;

before the "return" statement and throw some other code in there to deal
with wrap around.  Same old covert channel, just slightly harder to use.

If you look at the PIDs you will see that the last byte is sequential.

>>This is actually fairly useful.  When I want to spy on a process with
>>`crash', it's easy to calculate the index into the process table which
>>I need for the `u' command.
>
>	I always looked at the output from the 'proc' subcommand, then
>	used the slot number for 'u'.....

Charles is right on this one.

% expr PID / 256

is a LOT easier than wading through hundreds of lines of output from "proc".
-- 
John F. Haugh II      | Quality is ... knowing who |  MaBellNet: (512) 823-8817
SneakerNet: 042/2F068 | your customer is and what  |      VNET: HAUGH at AUSVM8
[ DoF #17 ] [ TSAKC ] | your customer wants.       |  Disc: I speak 4 me, !IBM.  
Newsgroups: comp.unix.aix