On Friday 30 November 2007 11:02:26 am Joshua Brindle wrote: > Paul Moore wrote: > > On Friday 30 November 2007 10:31:57 am Joshua Brindle wrote: > >> Equivalence between every module? I don't see how this would possibly > >> work in practice, how would audit2allow know what caps to include when > >> it creates a new module? How would support for new caps come from a > >> policy upgrade when there are local modules present that don't have > >> them? > > > > I know this is more work both in the code as well as for policy writers, > > but how about two policy bitmaps for each module: one bitmap (call this > > bitmap A) indicates the capabilities that the module is knows about (i.e. > > the policy capabilities that were defined when the module was written) > > and one bitmap (call this bitmap B) to signal which capabilities should > > be toggled on? This way when you load/link/install a series of policy > > modules you can check to make sure that the union of all the B bitmaps is > > a subset of the intersection of all the A bitmaps. If this is not the > > case you can print an error and refuse to load the module, or load it > > with the offending capability turned off. > > I think this is way too complicated from a user point of view. I won't argue that it isn't more complicated than the other options presented so far ... > I don't want users to 1) have to know capabilities that have nothing to do > with their module It's probably worth trying to better define "user" in this case. Are you talking about the policy writer who is creating the module or the sysadmin trying to load the module? > 2) disable all caps by not including any in a module and potentially > hose their system. Wait a minute here, you'll have to explain this for me because I don't see how you jumped to that conclusion, I never said to disable all capabilities. Here is my thinking ... 1. System has policy installed and is working, or "not hosed" 2. Sysadmin tries to load new policy module which introduces a new capability which is not known/understood by all of the currently loaded modules, we can either: 2a. Fail to load the module and have the sysadmin report the problem, system continues without new policy, still "not hosed" 2b. Allow a forced load of the new module with the new capability disabled, the new module may not work correctly but hey we warned you ... potential "hosing" but should be easily repaired on the fly by removing the module -- paul moore linux security @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
