[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Secure 2.4.x kernel



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:matthew@sackman.co.uk]
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:JClay@techteam.com]
> > 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 <kellym@fb00.fb.org> 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 debian-security-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> > listmaster@lists.debian.org
> >
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>
>

--

Matthew Sackman
Nottingham
England

BOFH Excuse Board:
disks spinning backwards - toggle the hemisphere jumper.


--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org


---
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



Reply to: