Secure access to system calls for a library?
Jonathan Leffler <[email protected]> Wed, 9 Jun 2004 12:22:02 -0700
| Newsgroups | gmane.comp.security.programming |
|---|---|
| Message-ID | <OFBEBBC891.12C42628-ON88256EAE.0069D2CB-88256EAE.006A8F23@us.ibm.com> |
How can a library ensure that when it calls getuid(), it really calls the
system call and not a dummy provided by the application that is using the
library?
Context:
A library uses getuid() to establish the real user ID of the application
that is running.
The library is used by (untrustworthy) clients, and can be included into
their programs.
There is nothing much to stop the program including:
int main(void)
{
call_to_library_function(...);
return(0);
}
int getuid(void)
{
return(0);
}
Now, when the program is linked, the library gets to call the user-defined
getuid() function, not the system one.
On Solaris, you can defer the pain marginally by calling _getuid()
instead, but the user can define that too, and you could defer the pain
one step more by calling __getuid(), but the user can define that as well,
and then you're hosed.
AFAICS, the only reliable way for the library to know that it is really
calling the system call is for it to embed the assembler code for the
system call into its code, under its own name, and to use that name
everywhere. I'm hoping, desparately, that this is wrong.
[Yes, there is room to suppose that the library is at fault for assuming
the getuid() is reliable - but how do you establish the actual identity of
the program when getuid() can be subverted so easily?]
--
Jonathan Leffler ([email protected])
STSM, Informix Database Engineering, IBM Data Management
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"