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