James Morris wrote: > > Given that it's possible to allocate a security context on the fly, what > if we just rename alloc_security() to unregister() and leave it at that? > > It's better to have less hooks if we don't need them. > I agree with this approach if the goal is to minimize hooks. What alloc_scurity() and free_security() really do is notify the LSM that some object has been created that may need access control. But the LSM knows the create side from the first access, but doesn't know that the object has been removed. Can we apply this approach to the other security ops, or is notification of object creation before first access necessary for some security modules? > > > While this is an extra copy, it will probably be lost in the noise of the > context switch, and is not in a peformance critical network path. > > Would you expect to propagate the sys_ioctl hook to > security_ops->netdev->ioctl() in this case ? > fs/ioctl.c:sys_ioctl() calls the file_ops->ioct() hook, and every ioctl therefore gets intercepted. So, you can control ioctl access to all objects via this single call, I believe. However, you do set up potential race conditions where the user-space parameter is copied in the file_ops->ioctl() to check access, but then is later copied and checked again at the lower level. A multithreaded process could modify the ioctl()'s arg parameter between those two checks. > I think it would make a better API for LSM module developers if hooks are > always associated with their respective kernel objects. > I agree, but if we want to minimize hooks, then we need to find the middle ground between fewer hooks and finer control. -- Wayne Salamon wsalamonat_private _______________________________________________ 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 : Tue Jul 24 2001 - 07:58:27 PDT