Re: Possible system call interface for LSM

dawat_private

Greg KH  wrote:
>On Sat, Aug 11, 2001 at 03:38:47PM +0000, David Wagner wrote:
>> 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 :)

Huh?  Imagine an app with a saved uid of 0 but a euid != 0.
Such an app is allowed to do a setuid(0).  In my example, the
app is *allowed* by policy to do a setuid(0) operation, but the
app did not want to do the setuid(0) operation; yet the setuid(0)
operation was performed anyway, because of a mismatch between the
app's expectations and the installed module.

Anyway, if you don't like my example, I hope you see that you
can come up with a better one.

>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.

But the point is that we need a uniform standard to reliably
rule out ambiguous parses.  For instance, we need all modules
to agree that the first arg carries a token identifying the
intended module.  If different modules have different identification
protocols, there is no guarantee that such a type-confusion attack
cannot occur.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module