richard offer wrote: >Having one id per policy is going to mean that us (LSM) and then Linus is >going to be forced to take frequent patches to a header file just to >support a global name name space. This is a real problem with how MAJOR and >MINOR numbers were handled in pre-2.4. Why does this sound like we're re-inventing a filesystem, complete with hierarchical tree-based naming scheme, etc.? Here's a crazy thought. What if we used operations on a /proc fd instead of a dedicated syscall? For example, I think SELinux wanted an extended symlink() syscall that took an extra argument. So, rather than creating a new selinux_symlink() syscall, we let the SELinux folks implement the same functionality via a write() on /proc/security/selinux/symlink. (We could achieve the same end using an ioctl() instead, with some tradeoffs; the decision can be left up to the module writer.) For instance, the user code might look like: struct { int newarg; const char *oldpath; const char *newpath; } selinux_symlink_args; int selinux_symlink(int newarg, const char *oldpath, const char *newpath) { static int ctlfd = -1; struct selinux_symlink_args s = {newarg, oldpath, newpath}; if (ctlfd < 0) ctlfd = open("/proc/security/selinux/symlink", O_WRONLY); return write(fd, &s, sizeof(s)); } The kernel-side code might look like this: int proc_write(struct file * file, const char * buf, size_t count, loff_t *ppos) { struct selinux_symlink_args t; if (count != sizeof(t) || copy_from_user(t, buf, sizeof(t)) < 0) return -EFAULT; ... do something with t.newarg ... return sys_symlink(oldpath, newpath); } Note that, through a clever setup, we never have to worry about user/kernel pointer ickiness. Unless I missed something, this looks pretty clean. What do you think? Comments? Criticisms? _______________________________________________ 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 : Thu Aug 09 2001 - 16:22:43 PDT