[PATCH] memset_s() and talloc_set_secure()
Andrew Bartlett
abartlet at samba.org
Wed Mar 27 00:56:23 UTC 2019
On Tue, 2019-03-26 at 20:33 -0400, Simo wrote:
> On Wed, 2019-03-27 at 12:02 +1300, Andrew Bartlett wrote:
> >
> > It still seems, compared the the vast majority of talloc use that this
> > is a niche feature that can be implemented outside libtalloc using
> > existing features. We have found it incredibly difficult to remove
> > additional 'helpful' features from talloc and I'm keen to avoid it
> > where there is a practical alternative.
>
> If it were possible to do this meaningfully outside of talloc proper I
> would have not brought this up. Nut it isn't. The whole point of
> zeroization of secrets is to not leave them in memory, and dealing with
> reallocation is crucial for this to be working.
To be clear we already have this in _talloc_realloc():
/* don't allow realloc on referenced pointers */
if (unlikely(tc->refs)) {
return NULL;
}
So I don't take it as proven that talloc_realloc() proves this must be
done in talloc.
Likewise we could abuse the must-maligned talloc_memlimit() and trigger
on this instead:
if (tc->limit && (size > tc->size)) {
if (!talloc_memlimit_check(tc->limit, (size - tc-
>size))) {
errno = ENOMEM;
return NULL;
}
}
I'm hand-waving, I've not tested these and both would clearly be
categorised as a cludge (and talloc_reference() games probably would
need talloc_unlink() to free it specifically), and I would still
seriously suggest we skip both and just clearly document.
In short I would prefer this outside libtalloc for the first
implementation, and I still think that is viable.
Thanks,
Andrew Bartlett
--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
https://catalyst.net.nz/services/samba
More information about the samba-technical
mailing list