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: <823A64A2-C962-403C-A0EB-95EA79B2DB91@mac.com>
Date:	Sat, 24 Nov 2007 21:07:09 -0500
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Crispin Cowan <crispin@...spincowan.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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ