Philippe Biondi wrote: > The general architecture should be a modular one (!) : > * An enforcer componnent : > It is in fact a lot of hooks in the current code that are called when > the process do a syscall (which does not mean in the sys_* function) > These hooks are already there! (capable() calls, permission tests...) > * A decider component, that may change easily. > It will be called by the hooks and must decide to allow or not > the operation. It must have sufficient data to decide. We must note that > is must be called in process context, so that it is possible to store > per-process data in the task_struct. > I'd like to add one more to the list: * A reporter component, which allows one to audit/log what happened (success/failure, use of privilege, etc.) I'm sure this is way too early in the discussion to mention, but here are a couple of other topics that our group are particularly interested in. 1) as already discussed, abstract the capable() functionality to more of a permission() check which can be augmented as desired by your security policy. 2) break out the identity and capability bits from the task_struct and create an expandable credentials structure. (someone may have said this already too.) 3) let process credentials follow objects involved in IPC, such as sockets, semaphores, shared memory. A simple void * on things such as sk_buf would allow security devlepers to tag along security attributes. In a later message, Crispin Cowan wrote: > ... There's no way > that LSM can solve all security problems, it's just supposed to enable the > loading of a reasonable set of security modules. I can't agree more. The past 10 years of working with secure kernels has dragged me through SecureComputing's LOCK/SNS and Sidewinder projects, Secureware's CMW and HP's VirtualVault. I've also had run-ins with DT-MACH and heard all I ever wanted about MULTIX. So, now, I bear the scars of security and understand that no one group will ever agree on which model is best. IMHO, the issue at hand is more of what is "practical security"; what do most folks need? Since Linux is a kernel for the masses, the security model needs to be simple when used, and invisible otherwise. OK, so that probably didn't need to be said, but I feel better now. :) Regards, Scott Leerssen
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:23 PDT