Re: Secure access to system calls for a library?

Jack Lloyd <[email protected]> Fri, 11 Jun 2004 11:10:38 -0400
Newsgroups gmane.comp.security.programming
Message-ID <[email protected]>
On Wed, Jun 09, 2004 at 12:22:02PM -0700, Jonathan Leffler wrote:
> 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?

You can't. It's impossible.

> 
> 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.

[snip]

> 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.

It is wrong - that won't work either. :) The application can always 'patch'
your library to skip the checks. On more modern systems, you can't write to the
text space directly, but a sufficiently motivated application could copy your
library to /tmp, patch the lib to remove the getuid checks, and then load it up
dynamically (via dlopen or similiar).

-Jack