Date: Thu, 17 Oct 1996 19:03:42 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= <ache@nagual.ru> Cc: Guido van Rooij <guido@gvr.win.tue.nl>, freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <Pine.BSF.3.95.961017185238.26533E-100000@alive.ampr.ab.ca> In-Reply-To: <199610172157.BAA00344@nagual.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Oct 1996, [KOI8-R] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote: > > >=20 > > > bzero'ing a hash buffer is not a complete solution to the problem, > > > since the process may contain other potentially sensitive data > > > in its address space. What you really want to do is protect > > > the cores. > > >=20 >=20 > I consider it as a bad move too and performance degradation. > Why only DB? Why you don't automatically clear stack too? :-) >=20 > Passwords can be stored anywhere in the application, > and it is per-application task to clear sensetive data anywhere. Is there an efficient way for a process to clear all memory that was allocated and deallocated by any function that it has called but not, of course, memory it is still using? The issue came up from ftpd calling getpwnam that calls some DB routines. The DB routines allocate and deallocte the memory internally, so getpwnam does not know what memory DB used.=20 I guess that in -current it doesn't matter since the process won't core dump anyway since it has done a setuid(). As long as there is no way other than core dumps or attaching with ptrace for a user to get information from the memory space of a program running as their uid that was running as root, this isn't a problem in -current. However, I'm not sure I want to trust that idea. Is reading of /proc/<pid>/mem disabled if a program has done a setuid()?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961017185238.26533E-100000>