linux-kernel - Re: [PATCH try #3] security: Convert LSM into a static interface

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:	Thu, 19 Jul 2007 07:24:24 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Christian Ehrhardt <lk@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	James Morris <jmorris@...ei.org>,
	Chris Wright <chrisw@...s-sol.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Stephen Smalley <sds@...ho.nsa.gov>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH try #3] security: Convert LSM into a static interface

Quoting Christian Ehrhardt (lk@...e.de):
> On Wed, Jul 18, 2007 at 06:35:03PM -0700, Andrew Morton wrote:
> > On Sat, 14 Jul 2007 12:37:01 -0400 (EDT)
> > James Morris <jmorris@...ei.org> wrote:
> > 
> > > Convert LSM into a static interface, as the ability to unload a security
> > > module is not required by in-tree users and potentially complicates the
> > > overall security architecture.
> > > 
> > > Needlessly exported LSM symbols have been unexported, to help reduce API
> > > abuse.
> > > 
> > > Parameters for the capability and root_plug modules are now specified
> > > at boot.
> > > 
> > > The SECURITY_FRAMEWORK_VERSION macro has also been removed.
> > 
> > I'd like to understand who is (or claims to be) adversely affected by this
> > change, and what their complaints (if any) will be.
> 
> I am currently loading and unloading a prototype like security module
> on a regular basis. The fact that such a module can be loaded and
> unloaded (albeit in an unsecure way) greatly simplifies development.
> Thus this change will adversely affect me and probably also others that
> develop LSMs.
> 
> Additionally deployment of and choice among legitimate security modules
> that may or may not (yet) be part of the main kernel tree is simplified by
> an option to load these security modules (e.g. at boot time) into a running

Right, the ability to boot with security.capability=disabpled (or
whatever) and then load a custom module without having to use a whole
new kernel is something I'm sure end-users want.

Especially since compiling a kernel which works with, say, a default
fedora install, with lvm etc, is not imo for a novice (where novice
!= security novice).

Maybe there are no out of tree modules being used this way, or maybe
there are but I just don't know about them, or maybe like James says
they are all illegal modules and kill a puppy every time they are
loaded.

> kernel. This way a distribution can provide AppArmor, SELinux, SecLevl and
> whatever as options very much in the same way that this works for a driver.
> 
> > Because I prefer my flamewars pre- rather than post-merge.
> 
> You asked for oppinion. I do not plan to engage in any flamewars.

Ditto.  There is very loud support for this - which may mean there is
*broad* support for it.

If we could get a few (non-afilliated :) people who work with
customers in the security field to tell us whether this is being
used, that would be very helpful.  Not sure how to get that.

Or we just apply the patch and see who yells  :)

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