Andrew Morgan wrote:
> Its not so much why you are wrong, as being clear that we're not using a
> generic name and inadvertently limiting ourselves to a SMACK-like model...
>
It seems we all agree that it is a bad idea to tie a POSIX Capability to
one specific LSM model.
> 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...
An interesting observation. This is a core part of why I have always
found the hierarchical models BLP and Biba to be unsatisfying. These
systems essentially have one simple fixed policy "process label must
dominate object label to get access", and then you express all the rest
of your "policy" by labeling your stuff. It is impossible to manage such
systems without a MAC_OVERRIDE escape hatch of some kind, because the
"policy" is too simple and inflexible, e.g. it does not allow you to
reclassify anything.
> 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".
> and browsing through your SMACK patch, there are many instances where
> this capability is used as an convenience privileged override. However,
> in other situations, it appears as if the capability is required for
> basic SMACK operations to succeed.
>
> My sense is that there is a case to be made for: CAP_MAC_ADMIN and
> CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or
> whatever MAC supports it) requires privilege to perform a privileged MAC
> operation, and the latter for saying "OK, I'm without a paddle but need
> one" (or words to that effect).
>
I don't get the difference. Both seem to permit the process to violate
the MAC policy. I could make up a meaning for MAC_ADMIN that is
different from MAC_OVERRIDE in the AppArmor sense, but I don't want to
:-) and worse, I suspect the distinction would be different for each
LSM. So let not, and just have one MAC_OVERRIDE capability.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
-
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]
