Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

[Casey Schaufler]

--- Crispin Cowan <crispin@xxxxxxxxxxxxxxxx> wrote:

> 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.

I think that's fair.

> > 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...

That's the reason we have a privilege model, not just for
MAC, but DAC as well. The Unix/Linux model where administration
and system tasks are performed by normal processes that are
just a little bit special, as opposed to a completely separate
set of interfaces, often makes things look a little contrived.
This is one of the advantages of SELinux, with it's model of
complete specification.

> 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.

Weeeellllll... That's sort of what the "mandatory" is all about.

> >  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".

That SELinux doesn't require any capabilities is an artifact of
design on that LSM. The whole notion of privilege is somewhat out
of context when your model is to explicitly state how every possible
decision ought to go. That is one important philosophical difference
between SELinux and Smack, with Smack taking a higher level view
on policy and hence privilege.

> > 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.

I am pretty close to agreeing with Andrew that a distinction
between allowing a process to change the state of the MAC
configuration (e.g. set file or process MAC labels, add rules)
and violating the rules is in order. SELinux can ignore both,
AppArmor can ignore one, and the upcoming DG/UX port* can ask for
further granularity when they show up.

I will look in this direction and see if I can patches proposed
before the virus in my sinuses knocks me out completely.

Thank you.

----
*  DG/UX supported over 330 capabilities and is my personal
   poster child for excesses of granularity with regard to
   capabilities. I don't really expect to see a Linux port.


Casey Schaufler
casey@xxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/