On Wed, Apr 11, 2001 at 09:00:07PM -0700, Andrew Morgan wrote: > > I could imagine some run-time method for dynamically replacing > security.bz2 with some obscurity.bz2 or something, but again, this would > be a method consistent with the initial security policy and would > require some careful impedence matching between the data-structures of > the old and new policies. I was thinking simple modules, not compressed kernel images :) So if a user wants the current POSIX capability model, they choose that one to be compiled in, or built as a module, so they can at a later date, pick that one to be loaded, or load up LIDS or RSBAC if they want to at a later date (like after init has started up). But the perprocess security model does sound _very_ flexible, who controls which process gets which security model assigned to it? Will we have pluggable security managers too? > For what its worth, the full POSIX(sic) capability model which includes > inode attributes, requires that 'capable(X)' be implemented, and that > the sys_exec() be able to query a file for its capabilities prior to > executing it. It also requires a system call interface for > getting/setting capabilities on inodes and processes. If one, indeed, > wants to use this as a prototype for a plug in security model we'll have > to support at least these hooks. I agree, the current capability model has to be supported is a given. A few of us here have a very rough cut that moves the capability model out into a loadable module, with a "generic" security interface. Give us a few days of fleshing it out some more and we'll post it to the list for comments. A question, does the kernel's current capability code meet the POSIX model? I was under the impression that POSIX never released a final recommendation for capabilities. Any pointers would be appreciated. thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:21 PDT