Re: Possible system call interface for LSM

From: David Wagner (dawat_private)
Date: Sat Aug 11 2001 - 08:38:47 PDT

  • Next message: Greg KH: "Re: [patch] Socket Receive Hook"

    Crispin Cowan  wrote:
    >IMHO, this is The Application's Problem.  [...]
    >[...]  An application that wants to be non-brittle should
    >inspect error codes coming back from sys_lsm, looking for a return code of
    >"EWTF?" ;-) and react appropriately.
    I'm probably being paranoid, but it seems there is little the application
    can do to gain confidence that its request won't be misinterpreted.
    Who knows, some aspects of the syscall-protocol exported by both modules
    may be similar enough that you don't get a EWTF but you do get some
    action taken that the app wouldn't have approved of.
    For instance, maybe in SubDomain sys_security(SD_CHANGEHATS, s) means
    ``change to subdomain named by s, or, if s==NULL, go back to the original
    subdomain'', and maybe in SELinux sys_security(SE_SETUID, u) refers
    to an extended setuid() call, e.g., ``change all uids to u, and change
    security labels to the default one associated with u.''  Now imagine that
    an app thinks SubDomain is running and calls
    sys_security(SD_RESTOREHATS, NULL) to go back to its original subdomain
    context.  If actually SubDomain has been removed and SELinux put in its
    place, and if SD_RESTOREHATS == SE_SETUID (remember, each module is
    managing its own namespace, so they might both be #define'd to 1 or
    something), we have trouble: SELinux will interpret this as a setuid(0)
    and change all uid's to root, which might create an inadvertent security
    hole (maybe we had an app running with saved uid 0 that didn't expect
    to be running with euid 0, and now this can be exploited, like in the
    wuftpd tractorbeaming attack).  Maybe this example is far-fetched, but
    I don't see what an app can do to reliably avoid this failure mode.
    The easies solution, IMHO, is not a callback, but rather to be more
    explicit in the syscall interface: for the app to pass along with each
    syscall a token that uniquely identifies which module's protocol it
    expected would be used for interpreting that syscall.  I'm not sure
    whether this problem is significant enough to justify such a fix, but
    it's not hard to fix if it seems troublesome.
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Sat Aug 11 2001 - 12:11:51 PDT