Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c
To: Karl Denninger <karl@Mcs.Net>
From: Justin T. Gibbs <gibbs@freefall.freebsd.org>
List: tech-userlevel
Date: 10/17/1996 23:10:46
>> Did you miss a portion of this thread? I think that Jason already
>> addressed all of these issues.
>
>I don't think so. Please enlighten me.
How civil.
>> The program can core dump, the core dump will simply only be readable
>> by root.
>
>IMHO, and sorry for being blunt, but that's a crock. So now you're going
>to drop a core file in a user's directory that's root and mode 700 --
>regardless of how umask is set, etc?
In either case, the core dump lands where it lands. If the user gets
upset about this file sitting in their home directory, maybe he/she will
even tell you about it so that you can determine the cause of the core
dump. If they don't want to tell you, they can still remove it since
they own the directory. Remeber that the core dump happens in the
current working directory or the process, so its not guaranteed that
the core dump will happen there.
>Its better to not have the problem in the first place.
Sure, core dumps should be rare. When a core dump occurs, do you think
your paying customers should diagnose and fix the problem? I would expect
the system administrators to fix problems with system utilities.
>> There are already protections enforced to disallow non-priveledged users
>> from ptracing programs that are setuid/setgid.
>
>A program which calls setuid() isn't SUID any more. Once done, that's
>terminal (and can't be "recalled").
The saved UID is not perterbed which allows you to determine that the
program was setuid.
>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.
>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.
>--
>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!
--
Justin T. Gibbs
===========================================
FreeBSD: Turning PCs into workstations
===========================================