Sometimes there is a conflict between security and the development
principles of abstraction (information hiding) and reuse.
The problem is that some high-level library routines
may or may not be implemented securely, and their specifications won't tell you.
Even if a particular implementation is secure, it may not be
possible to ensure that other versions of the routine
will be safe, or that the same interface will be safe on other platforms.
For example, I've not been able to assure myself that tmpfile(3) is
secure on all platforms (see Section 6.7.1.2);
its specifications aren't sufficiently clear to give me confidence of this.
In the end, if your application must be secure, you must sometimes
re-implement your own versions of library routines.
Basically, you have to re-implement routines if you can't be sure
that the library routines will perform the necessary actions you require
for security.
Yes, in some cases the library's implementation should be fixed, but
it's your users who will be hurt if you choose a library routine that
is a security weakness.
If can, try to use the high-level interfaces when you must
re-implement something - that way, you can switch to the high-level
interface on systems where its use is secure.
If you can, test to see if the routine is secure or not, and use it if
it's secure - ideally you can perform this test as part of
compilation or installation (e.g., as part of an ``autoconf'' script).
Sometimes this kind of run-time testing is impractical (e.g., testing for race
conditions).
Download
