* Davi Arnaut (davi.arnaut@private) wrote: > Hello, > > On 5/5/05, Chris Wright <chrisw@private> wrote: > > * Davi Arnaut (davi.arnaut@private) wrote: > > > [PATCH] LSM: Add user_struct (alloc/free) hooks > > > > > > Allow a more fine-grained (and less complex strategy) for security > > > modules (models) based upon user tracking. A move toward > > > "a full-fledged user tracking system".. > > > > This needs a better explanation. How do you expect to populate/use > > these new blobs? > > With the traditional user_struct we cannot implement a _simple_ and reliable > URT (User Resource Tracking) system or provide a role basead grouping > within the kernel (through modules). This patch gives us the base for a system > wide tracking of users instead of a process-based limit, which enables > us to audit > and enforce global per-user system policies. Why can't this be done with normal task blobs? The mechanism for populating these could key off of the user struct (IOW, you can share them yourself). This could be more flexible if you don't care to track by uid but by some other grouping. > For exemple, this patch allows me to implement, with the current set of hooks, > a global per-user task|inode|socket|shm|sem limit and track abuse of those > resources. This is a great feature which can help sysadmins to distribute > resources along a group of users, especially true for servers full of > resource hungry users. Is it simple enough that we can expand existing rlimit infrastructure? > > What do you do on switch_uid to update state? > > Nothing, switch_uid only happens on reparent_to_init and set(re)uid > and there are hooks for those, should we care ? You may want to unaccount/reaccount at that point, no? > > You don't need to add NULL ops to the selinux_ops, registration will > > handle that fine. > > Placed on the terms of "hey, fill me in". OK. Fine for generating comments, but not something that's mergable. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Thu May 05 2005 - 15:41:54 PDT