Date: Sat, 19 Oct 1996 16:57:04 +0400 (MSD) From: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" (Andrey A. Chernov) <ache@nagual.ru> To: deraadt@theos.com (Theo de Raadt) Cc: hackers@freebsd.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <199610191257.QAA00669@nagual.ru> In-Reply-To: <199610190005.SAA28067@zeus.theos.com> from "Theo de Raadt" at "Oct 18, 96 06:05:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> well, that would be foolish. there are other issues which noone > outside of openbsd has thought of yet. we've found about 3 other > related holes, and i can definately say you should not back that > change out. It seems that you not follow this discussion well, so I repeat essential points for you: 1) Application can store its secure data ANYWHERE, db, stack, etc. So, cover only one area gains nothing. 2) Any attempts to automatically erase secure data ANYWHERE leads to performance degradation for applications which not want it. 3) Dropping core isn't a point, once SUID programs must not drop non-superuser readable cores. 4) Applications/functions which want to erase its secure data in the memory (if it care about physical memory browsing) must do it by yourself. 5) Getpw*() family can be treated as example of 4), so it can do it, but definitely NOT generic db close. 6) So, some erasing function must be added to generic db interface which allows endpwent() to erase its memory when called directly. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Andrey A. Chernov <ache@nagual.ru> http://www.nagual.ru/~ache/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610191257.QAA00669>