RE: crypted swapspace?

van Heusden, Folkert (Folkertvan.Heusden@getronics.com)
Tue, 14 Dec 1999 14:58:40 +0100


> > I suddenly realised that if your system crashes or reboots in
> > a not so clean way, all
> > kinds of sensitive data may end up in the swapfile, readable
> > for every malicious user with a bootdisk.
> > As far as I know, it is not possible for unprivilidged users
> > to lock pages permanently
> > in RAM, so another approach should be taken.
> > The most preferable way would be a crypted-filesystem wherein
> > you would have a swap-
> > file. All of that outside the kernel. Is it possible to swap
> > to something controlled
> > by a userprocess? Or is a specific crypted swapper more
> > appropriate?
> Swapfiles are already too time consuming against swap disks.

Yeah, but then: if something needs the protection that makes it
important not to be able to read trough the swap-space, it's
probably not a problem to have loads of memory. You still need
some swap, though, since (in my experience) you never can depend
on the total amount of mem needed (it really sucks, seeing a
machine going down because of a memory-leak :-( )

> AFAIK nothing in that domain has been implemented yet but
> it should be kswap module relevant.
> Maybe you could take benefit of new hardware crypting ???

Nah, I'd rather have some generic user-space hook where you can
hook-in your crypting routine. Because of export-reasons.

> btw, any malicious user can go anywhere with a bootdisk
> taking advantage of any _original_ file so don't worry !

Not really; you have, of course, all important files on crypted
filesystems. That will also mean that you need to have some "enter
password" or "insert smartcard"-mechanism before the system can
boot-up; you don't want any passwords in plain-text.

> What would be more interesting is the way system's recovered
> after a crash ... mounting that crashed volume from elsewhere
> should generate syncing so that you won't be able to see
> a _real_ image of the swap (that one's kept for partitioning
> concept that's all).

I'm not sure what you mean.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/