Re: Secure access to system calls for a library?
From: Glynn Clements (glynn.clements_at_virgin.net)
Date: Fri, 11 Jun 2004 13:01:00 +0100 To: Jonathan Leffler <firstname.lastname@example.org>
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
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
> 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@example.com>