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

[Casey Schaufler]

--- "David P. Quigley" <dpquigl@xxxxxxxxxxxxx> wrote:

> 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

Two very important things to consider:

The LSM is designed to be a restrictive mechanism. An LSM module
is not allowed to grant access that would be denied by usual
mechanisms. There are composition problems, but nothing that is
worse than the problems you have to deal with when a filesystem
is mounted read-only. True, one LSM module could muck with the
data used by another, but that's something you can do today with
setxattr() calls in an application.

Which brings up the second important point. The argument above
has nothing whatever to do with mechanisms provided by the kernel
and everything to do with the privileged applications used to
administer a system. Those applications need to be written so as
to deal properly with unexpected access failures, such as might
be induced by a filesystem mounted read-only or being full. I
am aware of the Holy Grail of a security package that does not
interfere with the operation of "normal" administration. How close
you can come to that in independent of wether your kernel is
an integrated "security solution" or a collection of composed
modules.

This discussion is amazingly disconnected from the issues of LSM.


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