On Thu, Dec 07, 2000 at 07:42:10PM +0100, Andi Kleen wrote:
> 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.
Your above statement looks different, but if that is your intention, your are
right.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
|