[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume
Michael Riepe a écrit :
>
> On Fri, Aug 09, 2002 at 08:26:50AM +0000, Nicolas Boulay wrote:
> [...]
> > >>> Kernel does not have it's own ASI. It is in the memory space in
> > every process.
>
> That depends on the OS.
>
> > Note that it may be possible to use a single set of access bits - if
> > they are valid for both user and supervisor mode (I'll have to think
> > that over).
> >
> > >>> there is always the same conceptual probleme : the kernel decide the
> > right to put in the tlb. It's one of it's role. Usually kernel is always
> > trusted.
>
> And exactly that is the problem.
>
> > But `supervisor mode is allowed to access everything' is a
> > BIG mistake.
> >
> > >>> Maybe. x86 is a big shit in this topic, but i have never heard about
> > tricks to compromise the kernel that way. Kernel hacker meet at lsm does
> > not speak about that (grsecurity patch maintainer (who mainly try to
> > simulate a true none executing bit in x86), VM designer of the hurd).
> > Maybe you discover a new concept of cracking. But i think it's really
> > easy to verify the pointer given by the user process.
>
> Depends on the OS, again.
>
The real and only danger is to given a kernel page to a kernel function.
I don't understand the problem of using software verification of it. If
the kernel is bad written it's is problem !
> > >>>Because the kernel is trusted, i can't imagine that you could
> > compromise it's security by a call to it's own API. Because kernel could
> > change the right in the tlb it could access what ever he want. If you
> > want to make things like chmod (that could unallowed to access a file
> > but a run of chmod could change that), how could the kernel be run
> > without virtual adress. I think that should be done during task switch
> > (christophe ?).
>
> *Because* the kernel ist trusted, it is one of the main targets for
> attacks. If you manage to hack the kernel, you can do everything
> (compare root kits and `trojan' kernel modules).
What you speak about is the use of kernel modules of linux used to
hijack os call to hide a back door or something like. It's possible
because this module run in kernel space : that not the case in
microkernel os. And this module could only be loaded if you gain the
root access. So before puting a kernel code, you must have root access.
> Therefore, the kernel
> needs *more* protection than a (user) process with root privileges,
> not less.
Because the kernel (or the tiny part of the microkernel that have all
the right : VM and scheduling) must have all the right. It's a conceptal
point. How could you restricit the right of a kernel that have all the
right : it's like setting rwx specific right for root in a unix file
system. For me, it does not make a sense.
All the danger you speak about could only be done at the design of the
OS. It's a story of right management. F-cpu could provide means for
that. But rwx bit for superuser mode...
Kernel will avoid to read or write in specific pages and trap in kernel
and make a kernel_core_dump ? I really need the opinion of Christophe.
Maybe a rwx specific right for defining a new ring for librairy could be
used ?
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/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/