> Hmmm I don't buy that this *couldn't* be done on the Intel. > I might be overstepping my knowledge, but I'm sure there > *must* be a way.
> Going back to my 68k days, it would have been fairly easy > to write this. Hey, I'm not an Intel assembly/opcode expert, > but it seems to me, I think that you could sit something right > in on an interrupt that would alert when a fork/exec call > was being made -- it wouldn't take a rocket scientist to > figure out that if you could take an interrupt/event on > this type of sig, you could certainly redirect the behavior > or outcome. You've misunderstood. I was stating that it would be hard to _protect the stack against overruns_ on the Intel platform. What you're talking about has nothing to do stack protection. Fork and exec (being syscalls) are already handled as software interrupts, so what you're talking about doing is what the kernel already does. > The examples pointed out (electric fence, st. james etc.) are > fine "workarounds", but they all look a little too "patch-like" > for it to be something that is "industrial strength". > I just think that intercepting the syscalls like fork and exec > at the kernel level for anything that is not "privy" should > be a feature of the kernel. Statements like this lead me to question whether you really know what you're talking about. Electric Fence is a tool for debugging heap overruns and has nothing to do with access control in the kernel. St. Jude is _exactly_ what you're claiming is necessary: it's a tool for intercepting syscalls at the kernel level. And, to be honest, where the hell else would you intercept a syscall? Kelly