> 
> >Karl Denninger <karl@Mcs.Net> writes:
> >
> >> If there was a separate "destroy-data" call, that would be ok.  But there
> >> isn't, and as such the ONLY way to have any security in these dbm routines
> >> is to have the system enforce it.
> >
> >   Adding the call seems easy enough, and seems the most elegant solution.
> 
>    It doesn't solve the real problem. The problem is that applications that
> were privileged might read sensitive data and store it internally. The dbm
> routines are only one instance of the "store internally" problem. There are
> countless other cases where similar things could happen...even temporary
> garbage on the stack can be a problem.
>    The ONLY solution is to not allow coredumps of processes that might contain
> sensitive data. The change that was made to hash_buf.c should be backed out
> and attempts should be made to ensure that the coredump won't happen in cases
> where sensitive data may be a problem.
> 
> -DG
> 
> David Greenman
> Core-team/Principal Architect, The FreeBSD Project

I respectfully disagree.

It is one thing to be responsible for data under your control (anything you
allocate on the stack or in the data segment).

It is another to try to force people to be responsible for data which is
under the control of the *system*, when the data types involved are opaque.

If you're arguing for no core dumps of anything which could contain
sensitive data, then the bottom line is that you have to decline any of the
following:

1)	ptrace() on any process which was STARTED Suid (not "currently is"
	SUID).  This precludes debugging on a process in this state.

2)	Any process which starts with the SUID or SGID bit on must
	internally decline to dump core (regardless of ulimit settings) at
	all times -- both while SUID and *IF SUID IS REVOKED BY THE JOB*.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1 from $600 monthly; speeds to DS-3 available
			     | 23 Chicagoland Prefixes, 13 ISDN, much more
Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 248-9865]     | Home of Chicago's only FULL Clarinet feed!