On Sat, 9 May 2009 03:46:28 +0100 Alistair Crooks <a...@pkgsrc.org> wrote:
> On Fri, May 08, 2009 at 01:18:38PM -0400, Perry E. Metzger wrote: > > > > "Alistair G. Crooks" <a...@netbsd.org> writes: > > > > > Module Name: src > > > Committed By: agc > > > Date: Fri May 8 06:06:39 UTC 2009 > > > > > > Modified Files: > > > src/crypto/external/bsd/netpgp/dist: TODO configure configure.ac > > > src/crypto/external/bsd/netpgp/dist/src/bin: netpgp.c > > > src/crypto/external/bsd/netpgp/dist/src/lib: config.h config.h.in > > > crypto.c misc.c netpgp.c openssl_crypto.c reader.c signature.c > > > signature.h version.h > > > > > > Log Message: > > [...] > > > + if setrlimit exists, set the core dump size to be 0 > > > (with thanks to mrg for the reference implementation) > > [...] > > > > What's the threat model this is protecting against? Presumably, if a > > user can execute the program, and the program can read his keys, the > > uesr can already read his own keys, so having a core dump doesn't give > > the user information he didn't already have. > > Heh, yeah, it's not really to do with keys, much more the passphrase, > which is dynamically allocated in a number of places in the library, > and I haven't finished auditing all of the places just yet. I've > added code to zero out that memory after use when I can - some more > are still needed. > > The threat that I'm protecting against here is that of information > disclosure coming from committing the passphrase to disk in a core > dump. Having to remember to rm -P the core dump file is a pain, you > don't get a second chance at it, and after that there is still the > problem of any spared sectors. I suspect you don't want a re-run of > the tls vs. agc wars from a month ago. Whilst most people will use > an encrypted block device of some description, others are prevented > from doing that for various reasons. I'm especially sensitive about > passphrases here, since there's no way of changing a PGP passphrase > short of generating a new key. > > I'd really recommend source-changes-full for reviewing the changes > that are made - the setrlimit(2) call is only made in the driver > program, not the library. > > Regards, > Alistair I recall reading a paper about storing sensitive data in shared memory blocks, I just can seem to find it. -- Adam Hoka <adam.h...@gmail.com>
