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