intercepting system calls

From: Philippe Biondi (philippe.biondi@enst-bretagne.fr)
Date: Fri Apr 13 2001 - 00:47:49 PDT

  • Next message: Philippe Biondi: "Specifications (the beginning)"

    On 13 Apr 2001, David Wagner wrote:
    
    > Philippe Biondi  wrote:
    > >The problems that it raise and that we must resolve :
    > >* How to attach AC data to processes ?
    > >* How can we guarantee that we did not forget a check point ?
    > >* How can we manage security policies changes/cohabitation ?
    > >[...] Another big problem is the data persistence.
    >
    > It seems that there's a natural way to attach state to a process.  Add a
    > 'security_state' field to the task_struct which contains a pointer
    > to a linked list of 'void *' pointers (one per module interested in
    > this process).  Allow modules to register hooks on process creation and
    > deletion to allocate and de-allocate any memory needed.  Provide a way
    > for a module to get and set a 'void *' pointer to be associated with
    > a process.
    >
    > What do you think of this rough approach?
    
    There was actually 2 questions in this one.
    The first was the one you answered. The more generic and flexible
    implementation is indeed a chained list with each struct tagged by an
    security policy ID, followed by data needed by the security policy.
    
    The second question was about the way we'll recognize a process to say
    "this is a sendmail, here are its data, what it can do, what it can't". A
    way that work is indexing by device/inode of the binary. When a process
    exec, we search in our big database informations about the new binary
    being instancied (whose device/inode we know), and we associate data to
    its task struct (with surely some mix with the previous data of the
    father, sth like inheritage)
    
    
    
    --
    Philippe Biondi
    Systems administrator
    Webmotion Inc.
    http://www.webmotion.com
    mailto:philippe.biondiat_private
    Fax. (613) 260-9545
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:31 PDT