On Wed, 2007-10-24 at 14:58 -0700, Casey Schaufler wrote:
quoted text
> --- "David P. Quigley" <dpquigl@tycho.nsa.gov> 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.

This branch of the tree seems to have gone in a direction similar to the
stackable netfilter like architecture that was suggested by someone last
time this came up.

quoted text
> 
> 
> Casey Schaufler
> casey@schaufler-ca.com
> -
> 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

-
unsubscribe notice
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/