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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
