On 5/5/05, Chris Wright <chrisw@private> wrote: > * 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. Yes, but I would have to _duplicate_ the uid system wich essencialy does it all. Every hook-hit would implicate a "uid is already in our tracking system ?" kind of check. There is no other place for uid tracking, the user_struct is already used to track resources (mq_bytes, locked_shm, process, et cetera). There are a lot of patches floating around to "fix" this issue. They all essentially do the same thing, extending the user struct with a bunch of ints. > > 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? Yes, it very is simple, but rlimit is shell-based limit. Modifying that would bring much confusion. But in essence, that's what I'am trying to get, a system-wide rlimit (through a uid <-> RBAC role relationship). > > > 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? Yes, but those can already be achieved with the post set(re)uid hooks. > > > 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. Fine. > 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 - 16:10:14 PDT