Re: Possible system call interface for LSM

From: Greg KH (gregat_private)
Date: Sat Aug 11 2001 - 20:01:13 PDT

  • Next message: jmjonesat_private: "Re: Possible system call interface for LSM"

    On Sat, Aug 11, 2001 at 03:38:47PM +0000, David Wagner wrote:
    > 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.
    Actually, if the SELinux kernel module allows that to happen by _any_
    random user app, then the kernel module has a bug :)
    > 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.
    Exactly, if you're worried about someone unloading your module and
    loading a new one, while your userspace program is running, you need to
    handle this in your kernel module.  This isn't something a simple extra
    field in the syscall interface is going to solve generically.
    greg k-h
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Sat Aug 11 2001 - 20:03:38 PDT