Re: Secure access to system calls for a library?

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?

With a great deal of difficulty.

Sure, you can use _syscall0(uid_t, getuid), but then some other code
could ptrace() the process and intercept that. Or the user can just
run it under gdb; or, for that matter, under an emulator.

Essentially, whichever code gets run first gets to determine the
execution environment for the remaining code.

> The library is used by (untrustworthy) clients, and can be included into 
> their programs.

If you want to implement a security mechanism, it would have to go
into either the kernel, or into a separate (privileged) process. And
that's only secure against users who can't modify the kernel.

If you want to protect against privileged users (e.g. for DRM-type
purposes), you would need hardware assistance, along the lines of
TCPA/Palladium/NGSCB/etc.

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

Even that isn't reliable, for the reasons mentioned above.

-- 
Glynn Clements <[email protected]>