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]

Message-ID: <Pine.LNX.4.64.0710242326430.17781@fbirervta.pbzchgretzou.qr>
Date:	Wed, 24 Oct 2007 23:42:18 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
cc:	Simon Arlott <simon@...e.lp0.eu>, 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 Oct 24 2007 17:02, David P. Quigley wrote:
>> 
>> There has been a feature in the security framework that probably did
>> not get much attention. It looks like YAGNI first, but on a closer look,
>> it becomes useful pretty quick - secondary_register.
>> 
>> As more and more simple LSM plugins pop up, stacking/chaining by means
>> of secondary_register becomes attractive again, especially if these LSMs
>> target different actions. This is probably the most useful thing why
>> the LSM interface should remain modular:
>> 
>> # Secure my files
>> modprobe apparmor
>> # -*- assuming apparmor implemented secondaries -*-
>> # Secure my ports
>> modprobe portac
>> # More rights to users
>> modprobe multiadm
>> # -*- whatever else comes along -*-

>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. [...]
>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?

Of course, the example I gave assumed that each LSM had disjunctive
features. Apparmor is primarily known for blocking file access,
and portac for blocking bind(2). If one of these gets additionaly
functionality, it would be nice that code gets combined so that
tracking down the piece of code that caused a particular syscall to
say nay is easier to pinpoint.

>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.
>[...] 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.

I agree - if one does not get the magic behind LSM stacking, s/he
should not use it, or learn to use it.
However, if you grasp how it works (probably even easier to learn
than figuring out how to selinux), one should know that a pam_deny.so
even after a pam_permit.so will lock you down. Yeah, it's like PAM
stacking.
-
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/