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

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



-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 21/08/02
Objet: 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".

>>> This is the problem number one of the computer security, if it
became impossible to do it, you see what reputation could have the
f-cpu...

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

>>>> That's kernel code, call by user code. Not simple user code ! It's
kernel code with pointer given by user that could cause problem. This
problem are soon easly handle by cheecking the adress. This problem are
really not common compare to buffer overflow one but you prefer to add
many hardware to avoid to do the job in software... 

>>> Buffer overflow are really hard to catch. In this case, you juste
have to check the bound of the pointer, that's a realy easy and quick
task !

>>> I don't understand why you prefer adding 3 more right bits just to
replace a mask and a test in software. Chekcking parameter is a normal
thing when you call a librairy or a system call. Buffer overflow are
more than 30 % of the overall security bug's in C. What about such
kernel protection ? I have been at HAL conference, read some newspaper
abuot security, i have never read anything about problem with kernel
pointer.

>>> The only kernel problem, i knows, is the module system of linux. If
you have root access, you could load a module that catch every system
call and you can hide what ever thing you want (back door, trojan,...). 
  
>>> One of the advantage, i see for such system, is kernel debugging,
and building a kind of microkernel architecture in monokernel OS. But
such protection are usual done by puting the code in user land. 

>>>If linus don't want to do that, it's for speed. TLB trap could be a
really on overkill for performance. I have read that zero copy HTML
server maid by IBM (challenger of Tux) is quicker under Linux than under
Windows because of the use of a single big memory page for the kernel.
It's avoid hundred of tlb miss.

>>> For example, in Hurd/L4 only L4 is in superuser mode. It's only fex
hundred of asm line. It even delegate the security of the system to an
other kernel. So Why having right for such tiny piece of 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").

>>> ;p Nop ! Buffer overflow are used to gain privileges that you don't
have. So you try to crack root processes, you never mind to crack you're
own process, because you will only receive the right that you already
have. Furthermore, user didn't compile code for the kernel or execute
there code in superuser mode.
nicO

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


______________________________________________________________________________
Pour mieux recevoir vos emails, utilisez un PC plus performant !
Découvrez la nouvelle gamme DELL en exclusivité sur i (france)
http://www.ifrance.com/_reloc/signhdell

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