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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47480D76.8030701@crispincowan.com>
Date:	Sat, 24 Nov 2007 03:39:34 -0800
From:	Crispin Cowan <crispin@...spincowan.com>
To:	Andrew Morgan <morgan@...nel.org>
CC:	casey@...aufler-ca.com, Stephen Smalley <sds@...ho.nsa.gov>,
	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	chrisw@...s-sol.org, darwish.07@...il.com, jmorris@...ei.org,
	method@...icmethod.com, paul.moore@...com,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch
 added to -mm tree

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/