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. Call me crazy, but this smells like a new kernel project/ehancment? 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. Wouldn't it be nice to be able to run the kernel in "secure mode"? I'm curious to know if we could limit the amount of "root exploits" by this method, it would REALLY harden up security on a Linux box... anyone have any opinions on that? In other words: If you could take away the ability of a cracker to "buffer overrun" as a vehicle into a box, your basically taking away his best "weapon" to gain access... And if you do that, well, I think the amount of vulnerability goes way down. Gary -----Original Message----- From: Matthew Sackman [mailto:[EMAIL PROTECTED] Sent: Friday, December 21, 2001 3:01 PM To: debian-security@lists.debian.org Subject: Re: Secure 2.4.x kernel I don't know this for certain, but I've got a feeling that it's this kind of thing that would be very easy to implement in the Hurd - the microkernel would make it very easy to start adding daemons that provide a layer between requests for exec, forks etc and actually granting them. Otoh, the hurd may not suffer from these problems at all, or in the same way - I haven't worked with the hurd for long enough to know much more than that it *seems* to revolve around some truely excellant ideas which some people don't like! In any case it would probably require writing a daemon and re-writing the hurd call library to take advantage of it, though no re-writing of the user space daemons would be necessary afaict. Matthew On Fri, Dec 21, 2001 at 11:23:59AM -0600, Kelly Martin wrote: > As far as I know, Linux does not support doing that. So the way you do it > is modify your kernel to make fork and exec revokable syscalls, write a > syscall allowing a process to request revocation of unneeded syscalls, and > add that call to your daemon. > > Kelly > > > -----Original Message----- > > From: Robert Clay [SMTP:[EMAIL PROTECTED] > > Sent: Friday, December 21, 2001 11:17 AM > > To: debian-security@lists.debian.org > > Subject: RE: Secure 2.4.x kernel > > > > And how would one do that? > > > > >>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM >>> > > ...Taking away the fork and exec syscalls from a daemon which does not > > need to do either would be a good start. > > > > > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Matthew Sackman Nottingham England BOFH Excuse Board: disks spinning backwards - toggle the hemisphere jumper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.310 / Virus Database: 171 - Release Date: 12/19/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.310 / Virus Database: 171 - Release Date: 12/19/2001
