On Thu, Dec 07, 2000 at 07:32:29PM +0100, Christoph Hellwig wrote:
> 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.
I was not talking about immutable on device files, just on ways how
"unbreakable for root" security features like immutable could be circumvented.
When an attacker gets access to DMA hardware or to kernel memory she wins,
because she can modify your immutable files.
>
> >
> > >
> > > > 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.
I have no plans and no time to do that. The end result would probably
not be very usable as a desktop machine anyways.
-Andi
|