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. thanks, greg k-h _______________________________________________ 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 - 20:03:38 PDT