Re: intercepting system calls

From: talgat_private
Date: Fri Apr 27 2001 - 11:13:23 PDT

  • Next message: talgat_private: "Re: intercepting system calls"

    Crispin Cowan <crispinat_private> wrote:
    > David Wagner wrote:
    
    >> Jesse Pollard  wrote:
    >> >A file may have its permissions changed to deny the process access.
    >> >[...] may want to deny access to a file after forking [...]
    >>
    >> Well, if you want a policy that has these semantics, then you
    >> can't take advantage of not trapping on read()/write(), that's
    >> true.  Fair enough.
    >>
    >> On the other hand, this policy is "Not The Unix Way", as someone
    >> alluded to earlier.  In Unix, file descriptors are capabilities.
    
    > I disagree about "not the unix way".  Precisely because file descriptors
    > are (kind of) capabilities, and they can be passed around in a lot of
    > sloppy ways, 
    
    So there is only few ways I know of to pass file descriptors between 
    processes.
    
    Through inheritance via. fork/clone.
    Through shared descriptor tables via. clone.
    Through descriptor passing via. sendmsg/recvmsg.
    
    I don't see why these are "a lot of sloppy ways".
    
    > it is ineffective to pretend that restricting the right to
    > create such capabilities restricts the right to access the files. 
    
    Fair enough, one still has to worry about core dumps for example. 
    But there are few of these cases. In general I think that
    controlling access to descriptors provides an extremely effective
    mechanism for this.
    
    >The
    > capabilities themselves must be mediated via read & write.  Or at least
    > the ability to allow some modules to mediate read & write must be
    > provided.
    
    Why?, if you want to control access at the level of granularity provided
    by normal unix permissions (read/write etc.) then simply controlling
    access to descriptors is fine (again modulo stuff like core dumps). 
    If you wish to provide finer grain control you can simply pass along more 
    restricted capabilities, (for example socket or file descriptors that 
    filter read/write based on content) and this can be implement via. 
    the existing device driver interface, or by passing descriptors to 
    user level processes which mediate access.
    
    > Conversely, if someone presented me with a mechanism that promises that
    > file descriptors don't leak across processes, I'd have a VERY hard time
    > convincing myself that it was correct.
    
    I don't understand this argument. The sharing of descriptors respects some 
    small, well defined set of semantics, just like the rest of the system. 
    If you think that the semantics of the current Linux API could be improved 
    in order to facilitate the use of descriptors for constructing more general 
    security policies then I would concur, and would be intrested to hear
    what changes you think should be made. 
    
    
    --Tal
    
    
    _______________________________________________
    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 : Fri Apr 27 2001 - 11:16:15 PDT