RE: Secure 2.4.x kernel
>>Statements like this lead me to question whether you really know what
you're
>>talking about.
Nah, I never really claimed I knew what I was talking about. ;-)
Read back, I actually said that "I might be overstepping my knowledge..."
Just asking questions, trying to understand more about it.
I was just trying to illicit conversation on the topic. Thats all <shrug>.
I apologize if i pissed you off (or anyone else). I didn't mean too.
gary
-----Original Message-----
From: Kelly Martin [mailto:kellym@fb00.fb.org]
Sent: Friday, December 21, 2001 3:36 PM
To: 'Gary MacDougall'; debian-security@lists.debian.org
Subject: 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.
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
---
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: