Comment by isp | Hacker News Reader

Comment by isp | Hacker News Reader

Reminds me of the "Robin Hood and Friar Tuck" hack.

Excerpts:

> They dug around in the operating-system listings and devised a thoroughly devilish set of patches. These patches were then incorporated into a pair of programs called 'Robin Hood' and 'Friar Tuck'. Robin Hood and Friar Tuck were designed to run as 'ghost jobs' (daemons, in Unix terminology); they would use the existing loophole to subvert system security, install the necessary patches, and then keep an eye on one another's statuses in order to keep the system operator (in effect, the superuser) from aborting them.

> They found the bandit ghost jobs running, and killed them... and were once again surprised. When Robin Hood was gunned, the following sequence of events took place:

    id1: Friar Tuck... I am under attack!  Pray save me!
    id1: Off (aborted)
    id2: Fear not, friend Robin!  I shall rout the Sheriff of Nottingham's men!
    id1: Thank you, my good fellow!

> Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system.

> Finally, the system programmers did the latter - only to find that the bandits appeared once again when the system rebooted!

Quoted in the Jargon File: http://www.catb.org/jargon/html/meaning-of-hack.html

Original story: https://www.cs.utah.edu/~elb/folklore/xerox.txt

A couple things I wonder there:

How does Robin (id1) manage to print the "I am under attack" message? Shouldn't a kill be immediate?

Couldn't they just do something like sending a SIGSTOP to processes, or use killall in a tight loop? I get it's not Unix, but it seems reasonable similar concepts should exist.

Also, this is more in line with Ken Thompson's "Reflections on Trusting Trust"

You can put a signal handler in your program to catch the SIGSTOP and run some code before it gets killed.

You can't catch SIGSTOP or SIGKILL. If you're trying to eliminate a rogue process, you wouldn't as nice as to ask it to politely shut down. It could just refuse. So if you're killing it forcefully, it shouldn't get to print anything. If you're asking it politely, then it can just refuse to die and doesn't need a monitor process to restart it.

In this story this isn't Unix but I imagine the same should apply. If you're trying to terminate something with extreme prejudice, it shouldn't get any chance to print anything.

Maybe they used a heartbeat?

Sure, many things could be done for two processes to monitor each other. The confusing bit is this happening at all:

    id1: Friar Tuck... I am under attack!  Pray save me!

The most reasonable explanations to me seem that either this is wrong and didn't happen, or that it actually came from id2, and the source of the message is falsified just for fun, or in hopes to create additional confusion.

Can't catch those signals, but under a very specific sets of circumstances, they could be... not quite ignored, but basically, that is behavior.

Things which are pending completion of I/O won't die as soon as SIGTERM or SIGKILL are sent to them. If you have ever tried to kill a process which had open file handles on a stale NFS mount, you have experienced this behavior. Causing it to happen deliberately is a lot more challenging, as well as not having a process actually be BLOCKED due to I/O, but it was[1] doable.

[1] haven't tried to do this in about a decade, so won't speak about the currency of this approach, but back then, with some clever assembly and a kernel module, it was doable.

I almost feel like that's too commonplace to be noteworthy anymore? There are lots of annoying programs I try to kill only for them to be restarted.

Reply on news.ycombinator.com