Re: Non-US

[nisse@lysator.liu.se (Niels Möller)]

Robert Bihlmeyer <robbe@orcus.priv.at> writes:

> > A better approach is to simply encrypt pages that are swapped out
> > (either all swap, or configurable per user or per process).
> 
> That incurs significant overhead. Of the 76 processes running on this
> box right now, only two need that level of security at the moment.
> These are served fine with mlock(), IMHO.

This is perhaps not the best place for this discussion, but let me
expand a little. My main problem with the mlock approach is that
it assumes sensitive data is a special case. Keys, passwords etc need
protection (and can be protected using mlock(), assuming that (i) the
system allows it, and (ii) that you're willing to sacrifice physical
memory for it), and that the normal case for all data is that it is
just fine to write it to permanent storage.

I don't have any perfect real life example, but consider this story,
some of whose details are actually true:

I get a log file from a client's Roxen server, to help track down some
SSL-related problem. The file was generated using -DSSL3_DEBUG, which
by design writes information to the log that is equivalent of the
server's private host key. The log is from a real server, so its not
just a test key. The client trusts me not to misuse it.

Now, the client should be using pgp for sending the file to me, and I
should encrypt it onto some encrypted file system, or at least a
filesystem that's not backed up and which implements some reasonably
secure delete operation. The intention is that I'll work with the file
as long as I need it, and when the case is closed, I'll throw it away.
An attacker breaking into my system later won't get the client's key.

But what do I do with this log? I probably want to open it in emacs. I
may want to process it with tools like grep. I don't expect grep to
have an option for using mlock:ed i/o buffers (and I wouldn't expect a
user to know how to enable the mlock option of all his tools). The
file is 100 megabytes large, so having emacs mlock its buffer wouldn't
be an option even if emacs supported that. Besides, I don't have root
privileges, so I can't use mlock anyway.

I don't think mlock is a solution, in this and many other cases. I
also think it is quite hard to get mlock:ing right in the few programs
that support it (for instance, you have to ensure that the secret data
is never put into variables that are allocated on the stack (unless
you mlock the stack; I have no idea if that's reasonable in practice).

Encrypting the swap, on the other hand, is easy (from the user's point
of view) and robust. I'd enable that feature, either for my shell, or
I'll ask the root to do it system wide) before decrypting the secret
data, and then this particular problem goes away.

You're right that it causes some significant overhead, both in cpu and
memory (as Niels Provos' paper points out, while an encrypted page is
being written to disk, the clear text page should still be available
in memory, so we need one *additional* page for the encrypted
version). mlock also causes some memory overhead, as less physical
memory is left to other processes, but perhaps that overhead is
smaller.

If I understand things correctly, each Hurd process can use it's own
default pager, so if encrypted swap is implemented, it should be
fairly easy to make it configurable per process.

Regards,
/Niels

PS. I'm not trying to argue that mlock shouldn't be implemented on the
Hurd. I just want to encourage you to also consider encrypting the
swap, as that's at least a little closer to the Right Thing.