Date: Fri, 18 Oct 1996 08:24:48 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Cc: karl@mcs.net, jdp@polstra.com, ache@nagual.ru, guido@gvr.win.tue.nl, thorpej@nas.nasa.gov, phk@critter.tfs.com, freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <199610181324.IAA02709@brasil.moneng.mei.com> In-Reply-To: <199610180610.XAA28738@freefall.freebsd.org> from "Justin T. Gibbs" at Oct 17, 96 11:10:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Justin, I have been following this thread and I was a little puzzled by your reply. > >The problem here is that authentication data must be able to be *known* > >destroyed in the data segment BEFORE a non-privileged user can get to the > >image of the data segment via any means -- ptrace, procfs, core dumps, > >etc. > > > >If you do that, you get rid of the entire problem -- and if done in the > >libraries its not just ftpd that this fixes. > > Which is what is accomplished, just in this case its by the kernel (where > security should be enforced) not by a library. I assume (hope!) that you are saying that the "fix" in the "kernel" is appropriate protection of the core file, not somehow mangling the contents of the core file to provide this protection. > >What's the objection to clearing possibly-contaminated structures when a > >program signifies its done with a privileged resource? > > It causes any db client to pay this penalty regardless of what is stored > in the database. That is bad design. Would it be possible to extend the db interface to have a "suicide call" that wiped itself clean? Something that would not interfere with normal db functions, but instead act as an extension? I believe that the current passwd lookup paradigm is typically something like: 1) prompt_login() 2) prompt_passwd() 3) db_fetch_salt_for_login() 4) encrypt_passwd_using_salt() 5) bzero_passwd() 6) db_fetch_users_encrypted_passwd() 7) compare() Inserting a step 6a) db_suicide() would prevent structures containing "sensitive" data from being present in a process that would later run as a non-root process. And no matter how secure the core/ptrace handling is, I tend to agree with Karl that this is not particularly desirable. If I can somehow exploit a bounds check bug someplace, and cause the system to write me that data, it doesn't particularly matter if the process is suid or not. Is it likely to happen? I'm inclined to say "no" but I'm not dumb enough to say so with certainty. (inserting a step 3a) db_suicide is probably also a good idea, btw). I think that the ideal solution would address both of these concerns. But I do not remember enough about the Berkeley DB package to really know... I do remember that it is extensible, perhaps it would be "easiest" to add another map type that explicitly cleaned up after each access. Just trying to suggest some ideas, ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610181324.IAA02709>