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]

Date:	Sat, 24 Nov 2007 19:36:43 -0800
From:	Crispin Cowan <crispin@...spincowan.com>
To:	Kyle Moffett <mrmacman_g4@....com>
CC:	Andrew Morgan <morgan@...nel.org>, 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

Kyle Moffett wrote:
> 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.
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:

    * reboot to single user and hack away
          o hurts usability because you need physical presence to change
            policy, but is highly secure
    * there is some type that is tighter than unconfined_t but none the
      less has sufficient privilege to change policy
          o 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


> 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.
Which is more or less the distinction I was trying to draw between
hierarchical systems (MLS) and policy systems (SELinux TE, AppArmor,
etc.) that policy systems let you write yourself an escape hatch in
policy, and MLS systems don't. Or at least they need to kludge something :)

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/