Re: A Comment from User Space

From: Valdis.Kletnieksat_private
Date: Mon Apr 23 2001 - 12:33:27 PDT

  • Next message: Kurt P. Hundeck: "Re: linux-security-module digest, Vol 1 #41 - 7 msgs"

    On Mon, 23 Apr 2001 15:09:47 EDT, jmjonesat_private said:
    > What about a single, documented, standard call that may or may not return
    > anything useful, depending on the policy/module in place?  
    > 
    > lsm_advisory_type * lsm_error(lsm_advisory_type *lat);
    > 
    > which would fill in the structure (or whatever) with something standardly
    > meaningful or just NULL or "I COULD TELL YOU, BUT THEN I'D HAVE TO
    > KILL YOU" or the equivalent?
    
    How about this:
    
    for PAM, we have this sort of thing:
    
       rc = pam_function(...);
       if (rc) { perror(errno), pam_strerror(rc) };
    
    Of course, for syscalls, rc and errno are both used, so we'd need this:
    
    extern int errno, lsm_errno;
    
       rc = some_syscall(...);
       if (rc) {
          if (errno = EPERM) {
    	 lsm_perror(lsm_errno);
    	 }
          else perror();
       }
    
    And if a LSM wants to be opaque, it can return an lsm_errno that
    causes lsm_perror() to return 'Permission Denied' same as perror.  If
    it wants to be very wordy, it can pass back a 32-bit value that
    lsm_perror can send across an IPC to a daemon process that looks up
    the event in a journal and hands back a string saying "denied because
    this process is in user class FOOBAR and has already used its limit of
    mmap() calls per 5-minute interval".
    
    Now - how to ensure that /usr/lib/liblsm.so points at a lsm_perror()
    that matches the LSM?  Or is that a sysadmin/install issue? ;)
    
    /Valdis
    
    
    
    

    _______________________________________________ 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 : Mon Apr 23 2001 - 12:35:00 PDT