On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote:
Andrew Morgan wrote:
It feels to me as if a MAC "override capability" is, if true to
its name, extra to the MAC model; any MAC model that needs an
'override' to function seems under-specified... SELinux clearly
feels no need for one,
That's not quite right. More specifically, it already has one in
the form of unconfined_t. AppArmor has a similar escape hatch in
the "Ux" permission. Its not that they don't need one, it is that
they already have one. They get to have one because they allow you
to actually write a policy that is more nuanced than "process label
must dominate object label".
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.
Even then "unconfined_t" is not an implicit part of the policy, it is
explicitly given the ability to take any action on any object by
rules in the policy, and it typically still falls under a few MLS
labeling restrictions even in the targeted policy.
Cheers,
Kyle Moffett
-
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]
