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