Re: Secure access to system calls for a library?

From: Glynn Clements (glynn.clements_at_virgin.net)
Date: 06/11/04

  • Next message: Jack Lloyd: "Re: Secure access to system calls for a library?"
    Date: Fri, 11 Jun 2004 13:01:00 +0100
    To: Jonathan Leffler <jleffler@us.ibm.com>
    
    

    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 <glynn.clements@virgin.net>
    

  • Next message: Jack Lloyd: "Re: Secure access to system calls for a library?"