Crispin Cowan wrote: > > - the system comes up in "legacy" mode with the capabilities (but you > > might as well think of it as "root user can do anything", because that > > is hot 99.999% of people end up using the capabilities). > > > > - the "security environment" is started. Unlike all existing models, this > > "security environment" doesn't actually have to have _any_ practical > > compatibility at all with the legacy mode, as those things can be > > handled ourside the security environment using the proper legacy tools. Is this bootstrap process sufficient to accommodate all likely schemes? In this model, 'init' or some such application is loaded - with essentially traditional UNIX security, upon which one would build a secure house of cards...? Someone's 'security' model might be 'all privileged code needs to be digitally signed', it would fail in this case, because 'init' is as privileged as it gets and it doesn't get verified. One of the significant attributes of everyone's personal favorite kernel patch is that its your way from the start. It seems to me that one needs to be thinking about: 'sLILO' boots "kernel.bz2 + security.bz2" and that the first instruction executed by the kernel is under the eye of the 'system manager' (decompressed security.bz2). 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. 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. Cheers Andrew
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:20 PDT