On Wed, Oct 5, 2011 at 11:55, Nick Johnson <nickjohn...@google.com> wrote:
>
> Is potential usage of swap really relevant here, given what we've made
> public about how we treat our drives? What is your threat model?

I want to minimize potential exposure of previously processed
sensitive information in case of an appserver compromise. After all,
appservers run arbitrary user-supplied code. I'm sure your sandboxing
is good, but the risk is still high. Suppose some appservers are
compromised on June 1 and are fixed on June 15. If sensitive data is
only ever stored in memory, just the data that was processed between
June 1 and June 15 might have been affected. If there might be any
remnants of the data on disks, *all* previously processed data might
be affected. And that's what I'll have to say to my clients. (If you
won't tell us about the compromise, that's another story.) So
unencrypted swapping effectively makes me unable to delete data
permanently when it is no longer needed.

mlocking() provides defense in depth. On disks information can live
for much longer than in RAM. If sensitive data doesn't have to be
stored on disk, we'd better make sure it never is.

Alexander

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to