On Thu, Dec 07, 2000 at 07:19:27PM +0100, Andi Kleen wrote:
> On Thu, Dec 07, 2000 at 07:12:34PM +0100, Christoph Hellwig wrote:
> > a) it's at least harder for the attacker
> > b) for a even more secure system you will just disable that too
> >
> > > (e.g. working IMMUTABLE normally implies non working x server).
> >
> > No.
>
> It does. I recently did a study for the changes required for a secure
> (how to plug all holes that could be used to change kernel memory in a
> controlled environment), and the X server was one of the most prominent
> (unless you go to unaccelerated X, which is not acceptable)
> There were lots of others too.
Yes. But IMMUTABLE doesn't even work on device files (yet).
X will get offended once you will disable it's access to kernel memory, but
IMMUTABLE is currently not usable to do so.
>
> >
> > > Commonly accessed binaries like the ld.so can also be just modified in
> > > core.
> >
> > Sure. But you probably want to disable access to /dev/kmem, too
>
> Disabling /dev/kmem and module loading is trivial. The problem when you
> want to do a full job is auditing every weird ioctl and /proc function hiding
> in some device driver if they do not allow to modify foreign memory for root.
> A lot of them do.
That's a really good idea. Set up a mailinglist and I (and probably others)
will
help you.
--
Whip me. Beat me. Make me maintain AIX.
|