Joe Nall wrote: > http://github.com/joenall/mcstrans Thank you I will take a look when I get to it. > > OTOH I somehow feel safer to have the words 'core' and 'web' stored > > directly in the inode of the disk rather than rely on a run time mapping > > from some generic number. (That's why I don't like unix UID/GIDs too > > much either.) > > I disagree. I prefer something on the inode with predictable, portable > mathematical meaning. Adding web/code/fu/bar means that the policy on the > object is dependent on yet another config file/policy because you need > to encode the semantic meaning of those words somewhere. The beauty of the > current approach is that the kernel doesn't have to know word semantics > to do range dominance checks. I always thought that it was the c0 stuff that needed run time support to be semantical, at least to humans using it. There is nothing more mathematical about c0.c1023 than there is about apple, banana and cherry. Categories have no ordering. What really matters here is the set inclusion operator (dominance). About predictability I dare say that c0.c1023 attempts to create a fake sense of ordering where there is not. Therefore is slightly less predictable. And I'm not sure what you mean by portability. If it means transferring categories between systems then with fixed notation like c0 there is only higher chance of conflicting with other uses for the categories on the target system. While experimenting with this I found out that the biggest plus of the generic categories is that you do not need to reload policy, restart sshd, crond, etc. when you add new ones. (And God forbid removing them, I even managed to get a kernel panic while playing with MCS too much ;) But I'm not sure if this is a problem. Change of categories is a change in security policy and that is a major enough event to require restart of services which authenticate users. Michal Svoboda
Attachment:
pgpKsimS7SvNt.pgp
Description: PGP signature
