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 linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Aug 11 2001 - 12:11:51 PDT