Date: Mon, 21 Oct 1996 11:53:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org, dnelson@emsphone.com, deraadt@theos.com Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <199610211853.LAA06300@phaeton.artisoft.com> In-Reply-To: <199610200704.JAA27667@uriah.heep.sax.de> from "J Wunsch" at Oct 20, 96 09:04:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> linker set... linker set. Well, the requirement of this application > for the `secure free' is already known at compile time. Shouldn't it > be possible to just link another free() (kinda `overloaded') in this > case, thus eliminating any peculiarities of any flag testing? Well, if we were doing C++, and both free's were class-free's that were derivative from the same virtual base class, maybe we could do it automatically. If we were using ELF, and segment-attributed the code to distinguish the symbols in the library, and selected it as an ld argument, or using a code #pragma reference in the sensitive application, we could also do it automatically. Barring those two implementations, and my initial suggestion, I don't see how you could do it without exposing s symbol that you aren't allowed to expose globally (or you could pick a new namespace for it, I suppose 8-(). I *really* displike the idea of using global flag-variant code, and eating the flag compare overhead in the vast majority of programs (since the vast majority of programs couldn't care less). The suggestion by Charles that there needs to be global criteria, uniformly applied, would work, especially if you forced "sensitive" programs to manipulate their ID's and restore them, even if they didn't need to. Makes you wonder about Sybase (as an example), since it has it's own security enforcement mechanism seperate from obtaining root credentials. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610211853.LAA06300>