On Fri, Aug 10, 2001 at 04:20:12PM -0700, richard offer wrote: > > "call" does not define the data structure. It defines the version of the > private protocol you're using, it says nothing about other peoples > protocols. That's right. Who cares what other people's protocols are? You shouldn't. > Hands up who's using 1,2,3,4 for their "call" values ? > > If Stephen and I both use a cmd value of 1, but a different number of > params, there's going to be issues. No, Stephan's userspace program isn't going to work properly with your module loaded. That's all. What's the problem there? > My application will pass two values to the system call, Stephens policy > will read that okay but not be able to do anything with as the number is > wrong (it was the bottom half of a long long variable), he will probably > return -EINVAL. Or if his policy was assuming that they would be kernel > pointers then he wont have done any user->kernel conversion and .... Ah, but Stephans program should first validate that the kernel is running SELinux by some other method than the syscall (I've detailed that in a previous message). And so should yours. So there will be no conflicts if you validate that your module is loaded before calling the syscall. > If everyone picks a unique cmd, there are no problems, that's not going to > happen. There are going to be conflicts (and with one value of "call" > required for each system call, its going to happen quickly), lets manage > that now rather than later. What's to manage? A buggy userspace application? Your syscall handler better be able to handle that anyway, or else you have a security problem in your kernel module. You _have_ to validate your syscall arguments and data no matter what. See the 2.2.19 security fixes for examples of why you have to do this. Remember, a syscall is _not_ the way to check if your module is loaded. 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 : Fri Aug 10 2001 - 16:35:45 PDT