linux-kernel - Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

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: <1191253239.7672.76.camel@moss-spartans.epoch.ncsc.mil>
Date:	Mon, 01 Oct 2007 11:40:39 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	James Morris <jmorris@...ei.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	casey@...aufler-ca.com, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory
	Access Control Kernel

On Mon, 2007-10-01 at 08:07 -0700, Linus Torvalds wrote:
> 
> On Mon, 1 Oct 2007, James Morris wrote:
> > 
> > Merging Smack, however, would lock the kernel into the LSM API.  
> > Presently, as SELinux is the only in-tree user, LSM can still be removed.
> 
> Hell f*cking NO!
> 
> You security people are insane. I'm tired of this "only my version is 
> correct" crap. The whole and only point of LSM was to get away from that.
> 
> And anybody who claims that there is "consensus" on SELinux is just in 
> denial.
> 
> People are arguing against other peoples security on totally bogus points. 
> First it was AppArmor, now this.
> 
> I guess I have to merge AppArmor and SMACK just to get this *disease* off 
> the table. You're acting like a string theorist, claiming that t here is 
> no other viable theory out there. Stop it. It's been going on for too damn 
> long.

You argued against pluggable schedulers, right?  Why is security
different?

Do you really want to encourage people to roll their own security module
rather than working toward a common security architecture and a single
balanced solution (which doesn't necessarily mean SELinux, mind you, but
certainly could draw from parts of it)?   As with pluggable schedulers,
the LSM approach prevents cross pollination and forces users to make
poor choices.

Some have suggested that security modules are no different than
filesystem implementations, but filesystem implementations at least are
constrained by their need to present a common API and must conform with
and leverage the VFS infrastructure.  Different security modules present
very different interfaces and behaviors from one another and LSM doesn't
provide the same kind of common functionality and well-defined semantics
as the VFS.  The result of merging many wildly different security
modules will be chaos for application developers and users, likely
leading them to ignore everything but the least common denominator.
It almost makes more sense to merge no security modules at all than to
have LSM and many different security modules.

If Smack is mergeable despite likely being nothing more than a strict
subset of SELinux (MAC, label-based, should be easily emulated on top of
SELinux or via fairly simple extension to it to make such emulation
simpler or more optimal), then what isn't mergeable as a separate
security module?

-- 
Stephen Smalley
National Security Agency

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