Guillaume, I'm not aware of any plans for secure memory wiping
toggle quoted messageShow quoted text
specifically, but I can say that another track of security work is one of
several candidates for the next phase of work on Garden after OCS/runC
integration is completed.
That said, such a change may fall outside the remit of the Garden team; it
may be a platform wide change that involves changes to the stemcell.
On 23 September 2015 at 13:28, Guillaume Berche <bercheg(a)gmail.com> wrote:
Chris, thanks for bringing up this important security topic.
In terms of secrets an app is handling and carrying, I'd think its code
has generally limited sensitivity (e.g credentials or API key secrets are
rather stored in env vars). I'd expect memory to be much more sensitive
(e.g. holding user data), as well as state handed over to data services (12
factor apps are unlikely to store much state on their ephemeral file
So related to your question about securely wipping data upon app instance
deletion, it may be interesting to consider secure RAM wiping when an app
container exits (sometimes killed by the oomkiller leaving few opportunity
for the app itself to wipe out RAM before exit). See related discussions in
   . Quickly searching the bosh stemcell builder, and bosh
tracker I could not find mention of gresec or pax linux kernel
packages/patches that could strengthen RAM wiping after an app instance
Will, do you know if is there plans to tackle such kernel hardening ?
Related to secrets stored on disk in data services (p-mysql, p-redis), the
services should be designed to not provide access to previous deleted
service instances when normally functionning. The secured data wiping might
be useful if ever the data service itself would get compromised so that an
attacker would not be able to access data from deleted service instances
On Thu, Sep 17, 2015 at 1:38 PM, Will Pragnell <wpragnell(a)pivotal.io>
In Diego/Garden, container files are stored on btrfs subvolumes. When a
container is destroyed, the subvolume is removed with btrfs subvolume
delete. I don’t think this does anything particularly fancy, and I don’t
think it classifies as “secure deletion”.
On 17 September 2015 at 11:53, Chris K <christopherkugler2(a)yahoo.de>
I'm sorry for having to revive this topic, but I'm still unaware about
the deletion process.
Could you please specify the term "standard removal tool". What's the
[... ] i believe with standard removal tools.
standard? Is standard just the deletion of the pointer pointing on files /
segments, or is secure deletion state of the art?
I'd be thankful for any reference on documentation regarding this topic.
Thanks in advance.