RE: Rep:Re: Rep:Re: [f-cpu] TLB right + resume

[John Graley <JGraley@sonicblue.com>]

> -----Original Message-----
> From: Michael Riepe [mailto:michael@stud.uni-hannover.de]
> Sent: 20 August 2002 13:40
> To: f-cpu@seul.org
> Subject: Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume
> 
> 
> On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay wrote:
> [...]
> > > 3- execute librairy call to execute excve with /bin/sh to 
> have a shell
> > > access.
> > 
> > That's a SW problem.
> > 
> > >>> A compiler problem, so an abi problem. The last 
> security problem in
> > case of buffer overflow.
> > 
> > > 4- diseable any possiblity of buffer overflow.
> > 
> > Dto.
> > 
> > >>> ??? don't understand that word.
> 
> Sorry... it was supposed to mean "same as above".
> 
> > > 5- Protect part of the kernel (driver) from it-self
> > 
> > That's what you need fine-grained access rights for.
> > 
> > >>> Do you think it's wise to protect the kernel from it-self ? 
> 
> It's a side-effect when you protect the kernel from user code.
> 
> > >>> What you think about the idea of tagged page that could 
> only be used
> > by tagged read&write instructions (to protect data page of 
> the kernel
> > and return stack write) ?
> 
> I'm afraid that will help only if you compile all your 
> binaries yourself
> (otherwise, they might contain "trojan writes").

Surely it would be a simple matter in software to search through executables
looking for the op-codes of illegal instructions before execution?

Cheers, John
 
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/