Messages in this thread | | | Date | Mon, 26 Nov 2007 14:55:10 -0500 | From | Joshua Brindle <> | Subject | Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree |
| |
Kyle Moffett wrote: > On Nov 24, 2007, at 22:36:43, Crispin Cowan wrote: >> Kyle Moffett wrote: >>> Actually, a fully-secured strict-mode SELinux system will have no >>> unconfined_t processes; none of my test systems have any. Generally >>> "unconfined_t" is used for situations similar to what AppArmor was >>> designed for, where the only "interesting" security is that of the >>> daemon (which is properly labelled) and one or more of the users are >>> unconfined. >> >> Interesting. In a Targeted Policy, you do your policy administration >> from unconfined_t. But how do you administer a Strict Policy machine? >> I can think of 2 ways: > > [snip] > >> * there is some type that is tighter than unconfined_t but none the >> less has sufficient privilege to change policy >> >> To me, this would be semantically equivalent to unconfined_t, because >> any rogue code or user with this type could then fabricate >> unconfined_t and do what they want > > Well, in a strict SELinux system, someone who has been permitted the > "Security Administrator" role (secadm_r) and who has logged in through > a "login_t" process may modify and reload the policy. They are also > permitted to view all files up to their clearance, write files below > their level, and relabel files. On the other hand, they do not have > any system-administration privileges (those are reserve for sysadm_r). >
Ofcourse secadm can give himself privileges to anything he wants, that isn't necessarily the point though, he is trusted to change the policy. He is, however, protected from other people: he can't, for example, read user_home_t files. This protects the integrity of his environment and the processes he runs. unconfined_t, of course, does not have this protection.
> Under the default policy the security administrator may disable > SELinux completely, although that too can be adjusted as "load policy" > is yet another specialized permission. >
load policy is pretty course grained, there are ways to make policy modification privileges more fine grained though such as by using the policy management server.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |