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!"