Re: A Comment from User Space

From: Greg KH (gregat_private)
Date: Mon Apr 23 2001 - 21:09:17 PDT

  • Next message: Valdis.Kletnieksat_private: "Re: A Comment from User Space"

    On Mon, Apr 23, 2001 at 10:34:51PM -0400, Valdis.Kletnieksat_private wrote:
    > I'll meet you half-way on this one - I admit doing most of my coding
    > over on the userland side of the fence, and I don't really care if
    > it's actually implemented in the kernel patch or not.  So...
    > 
    > As long as we define an API, and have at least *some* hand-waving
    > of "a module could do this-or-that to provide it", I'll shut up
    > about the exact implementation.
    > 
    > My requirement is "the LSM interface needs the moral equivalent
    > of the PAM pam_strerror() routine", and that I know that if I
    > get an EPERM error in errno, that calling lsm_perror() will:
    > 
    > a) be guaranteed to be there (even if only as a stub)
    > b) Return either a more detailed description than EPERM or 'no further info'.
    
    What?  Wait a second.  Exactly how are we going to implement lsm_perror?
    A new syscall?  If so, you can't just return a pointer to a constant
    kernel string, that doesn't work...
    Who's going to write the userspace library?
    Who's going to provide the localization (the kernel sure isn't going to have
    localized strings in it)?
    
    Does this mean that the kernel module needs to keep around for every
    task the last error that it had?  Where is it going to store this?  (ok,
    it can just store it on the task structure, in its anonymous "blob").
    Remember, there is no way to hold a "global last security error" in the
    kernel, as there are zillions of tasks running.  That just doesn't work.
    
    And most important of all, who is going to write code to actually use
    such a thing?  I don't see the current Linux security projects offering
    up secure userspace tools to match their kernel patches (SELinux being
    an exception here, from what I have heard, but I might be wrong here.)
    Unless you do it yourself, none of the individual groups are going to
    start coding to a new kernel interface any day soon.  Hey, they have
    enough problem getting convinced that their code has security problems
    in it in the first place! (personal experience here, trust me, not a
    pretty thing...)
    
    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 : Mon Apr 23 2001 - 21:11:43 PDT