Re: [patch 0/5] Support for sanitization flag in low-level pageallocator

[Larry H.]

On 20:26 Thu 21 May     , Alan Cox wrote:
> > You don't always know this at page free time.
> 
> You do at buffer free time.

Alan, I think you will agree with me that forcing people to know what
they have to do exactly with their buffers when they will contain
confidential/sensitive data is suboptimal. Like it's been said before,
the clearing isn't the only issue here. We have pagination to disk,
re-allocation leaks, etc.

Rik conveniently recommended me to write a threat model for this and
that's exactly what will be done so the issues are clarified further
more. The text had been omitted form the patches to keep them reasonably
small.

> Still doesn't need a page flag - that is a vma flag which is far cheaper.
> Also means you can get rid of the stupid mlock() misuse by things like
> GPG to work around OS weaknesses by crypting the page if it hits
> disk/swap/whatever.

I had the intention to cover cases like gnupg's approach to
pseudo-secure memory (their mlock pool, the three pass memset wipe, etc)
with this implementation.

We would need to look into a sane approach for encrypting the data. That
was out of scope for my patches, so far. It adds further complexity and
might require more invasive changes (if we want to let the user select
the algorithm on runtime, etc).

Do you suggest a vma flag should be created for this as well?

> > I could also imagine the suspend-to-disk code skipping
> > PG_sensitive pages when storing data to disk, and
> > replacing it with some magic signature so programs
> > that use special PG_sensitive buffers can know that
> > their crypto key disappeared after a restore.
> 
> Its irrelevant in the simple S2D case. I just patch other bits of the
> suspend image to mail me the new key later. The right answer is crypted
> swap combined with a hard disk password and thus a crypted and locked
> suspend image. Playing the "I must not miss any page which might be
> sensitive even compiler stack copies and library buffers I don't know
> about" game is not going to build you a secure system - its simply
> *lousy* engineering and design.

The point is that the keys or sensitive marked pages should never, ever
be swapped to disk, by any means. Right now the patch only affects
kernel code, the task related flag and functionality patches haven't been
submitted yet.

Regarding retrieving the encryption keys, IVs, and so forth, why bother
reading the data remaining on disk? You can just retrieve them off
memory (ex. via rogue driver or some re-allocation bug scenario,
information leak or similar issue) and that's it.

> 
> Basically though - loss of physical control means you have to assue the
> recovered system is compromised. I doubt even TC is going to manage to
> spot firmware compromises on your CD-ROM drive, which thanks to the film
> industry creating a demand for altered firmware is a well understood
> field..

I don't see what physical compromise of the machine has to do with
anything about this patch and the issues it addresses. Although, the
real benefits from TC will be more about memory containment, untrusted
code injection prevention and so forth.

Basically things like preventing SELinux from being disabled via some
kernel vulnerability which let's an attacker abuse a write-4 primitive
(on x86_64 as well). Or patching the pagetables to make the kernel text
writable. Or injecting code in the .rodata section. Or redirecting an
IDT gate to some RWX mapping. The list goes on.

While other vendors might use this technology for locking down their
users, mutilating their rights and constrain their legitimate use of
their systems, we can use this technology for a beneficial purpose.
After all, that was the beauty of Linux since the start. We don't need
to follow a political or corporate agenda in these regards. Right?

> The cost of doing crypto on suspend to disk relative to media speed is
> basically irrelevant on a PC today. In the S2R case you might want to
> crypt those pages against an electronic pure read of RAM type attack but
> this is getting into serious spook territory.

If someone has access to an oscilloscope and the required equipment to
read data directly in that manner, well, the problem isn't that they
have access to your hardware. The problem is that you pissed off the
wrong people. And the list of things to attract such attention is
still, fortunately, short. Or so we believe.

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