Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

["David P. Quigley" <dpquigl@tycho.nsa.gov>]

On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 19:59, Simon Arlott wrote:
> >On 24/10/07 19:51, Jan Engelhardt wrote:
> >> On Oct 24 2007 19:11, Simon Arlott wrote:
> >>>
> >>>* (I've got a list of access rules which are scanned in order until one of 
> >>>them matches, and an array of one bit for every port for per-port default 
> >>>allow/deny - although the latter could be removed.
> >>>http://svn.lp0.eu/simon/portac/trunk/)
> >> 
> >> Besides the 'feature' of inhibiting port binding,
> >> is not this task of blocking connections something for a firewall?
> >
> >The firewall blocks incoming connections where appropriate, yes, but it 
> >doesn't stop one user binding to a port that another user expected to be able 
> >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
> >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
> >below 1024 and it's useful to be able to prevent users from binding to them 
> >too.
> 
> Indeed.
> 
> 
> 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 -*-

There is an issue that you overlook here and it is the successful
composition of security models. While your idea is appealing it presents
several problems. In your example you have 3 models with 3 policies.
AppArmor which has its own port security mechanisms is a MAC model that
from what I have seen appears to have a targeted least privilege policy.
This means that AppArmor picks applications it wishes to secure and
makes sure it can't do anything except what it needs to get its job
done. Your module multiadm takes a user which is completely orthogonal
to the concepts that AppArmor uses and gives him extra privileges. From
what I have read and correct me if I am wrong portac deals with users
instead of programs. Now lets try to reconcile this in a way that is
sane to the user/administrator.

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.

Dave Quigley

> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/