Re: Possible system call interface for LSM

From: David Wagner (dawat_private)
Date: Thu Aug 09 2001 - 16:15:54 PDT

  • Next message: David Wagner: "Re: Possible system call interface for LSM"

    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