[PATCH] memset_s() and talloc_set_secure()

Andreas Schneider asn at samba.org
Thu Oct 11 13:26:33 UTC 2018

On Thursday, 11 October 2018 13:15:17 CEST Stefan Metzmacher wrote:
> Am 11.10.2018 um 13:07 schrieb Andrew Bartlett via samba-technical:
> > On Thu, 2018-10-11 at 12:17 +0200, Andreas Schneider via samba-
> > 
> > technical wrote:
> >> Hello,
> >> 
> >> the attached patch adds memset_s() [1] and talloc_set_secure(). It will
> >> make sure that memory is zeroed/erased before freeing to not keep
> >> secrets around.> 
> > Stepping back a moment, how do you handle talloc_realloc()?
> > 
> > That either needs to be banned or handled to ensure the old memory is
> > wiped after a memcpy() to new memory (with performance losss).
> > 
> > (And that will all need tests).
> > 
> > Sorry this is turning into a can of worms, but if we do this we need to
> > do it completely.
> Yes, I also discussed privately with Andreas that we need to make sure
> talloc_report() doesn't leak the content.
> The current idea is:
> #define talloc_keep_secret(ptr) _talloc_keep_secret(ptr, #ptr);
> void _talloc_keep_secret(const void *ptr, const char *name);
> While I may prefer to pass name explicit.
> I guess talloc_asprintf_append* also needs special handling.
> We need to decide what to do with talloc_strdup() and even more complex
> talloc_asprintf(..., "%s", secret_talloc_string).

What do you mean? That in case we pass a pointer to such a function it should 
be inherited?

I think if you do that you should do it like:

char *password = talloc_strdup(talloc_secret_string);

And not magically to it. I think explicitly calling it is better.

> Do we force the caller to reuse talloc_keep_secret() or do we want to
> somehow inherit the secret state.

I would not inherit it, only talloc_realloc() should inherit it.

The current state is here:


Andreas Schneider                      asn at samba.org
Samba Team                             www.samba.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D

More information about the samba-technical mailing list