linux-kernel - Re: Linux Security *Module* Framework (Was: LSM conversion to 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, 25 Oct 2007 12:38:20 +0100
From:	"Simon Arlott" <simon@...e.lp0.eu>
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
Cc:	"Jan Engelhardt" <jengelh@...putergmbh.de>,
	"Adrian Bunk" <bunk@...nel.org>,
	"Chris Wright" <chrisw@...s-sol.org>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Andreas Gruenbacher" <agruen@...e.de>,
	"Thomas Fricaccia" <thomas_fricacci@...oo.com>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"James Morris" <jmorris@...ei.org>,
	"Crispin Cowan" <crispin@...spincowan.com>,
	"Giacomo Catenazzi" <cate@...ian.org>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to 
     static interface)


On Wed, October 24, 2007 22:02, David P. Quigley wrote:
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port.
>
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.

I agree that it can cause problems, but it's up to the modules themselves
to determine how to combine permissions with their immediate secondary
module.

Instead we now have a static LSM where combining features from one module
means duplicating it in another - then when two modules contain most of
the other's code, but perhaps vastly different configuration mechanisms,
someone will propose removing one of the two...

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