Re: Possible system call interface for LSM

crispinat_private

Lachlan McIlroy wrote:

> There was some minor discussion recently about modules needing to modify
> the system call table to create module specific system calls.  It prompted
> me to investigate a fixed system call for LSM that will multiplex the
> variety of system calls required for each different security scheme.  I've
> attached a patch of the proposed idea for people to comment on.

Asking Linus for a single system call, and then multiplexing it to serve
whatever LSM modules need, was actually a decision we came to some months
ago.  However, we then didn't do anything about it.  Thanks for getting the
ball rolling.

richard offer wrote:

> The only problem I have about having security.h maintaining the list of
> policy ID numbers is that that is going to have to change everytime someone
> writes a new policy.

I agree that it's kind of a hairy problme, and it's going to require some
kind of arbitration.  However, exactly what kind of arbitration is not
clear.  IMHO, it critically depends on our module stacking scheme.  To wit:

  1. No stacking:  if we strictly enforce that only one module can be loaded
     at a time (which we're not, this case is just for illustration) then no
     arbitration is needed at all.  Each module simply implements its own
     table of functions to be implemented, and applications are customized to
     the module.
  2. Stacking arbitrated by a module: the first module loaded is responsible
     for implementing the stacking.  It essentially has a LSM interface on
     its back end, and when called by hooks or the syscall, decides whether
     to process the action or pass it along to other loaded modules. In this
     case, arbitration is only needed between "families" of modules that are
     intended to work together.  This is consistent with the "vendor"
     oriented revision that Richard just posted.
  3. Fully generic stacking:  all modules can inter-operate, and be loaded
     simultaneously.  This is the only case that actually needs full
     arbitration of syscall numbers.  However, we've already established that
     it is impossible to support, and so we don't actually need full
     arbitration.

> And we're going to get into the issue of "we're not going to accept your
> policy in phase 1" even if all that's required is an ID number.

I do hope you're kidding.  The "not in stage 1" stuff is only to exclude
*features* from LSM 1 that cannot be justified as necessary to support the
scope of LSM 1 (access control) and thus demonstrate that we can build
something lean and mean.  I think it would be great if a partial audit module
that worked with LSM 1 was produced.

> Perhaps it should be vendor rather than policy specific ? It forces the
> vendor of the policy to be self consistant withing their organisation in
> terms of cmd codes and would require less changes to security.h before and
> after the code is mainlined ?

From above, it's clear to me that Case 2 is the desirable one, and so I agree
that the syscall numbers only need to be consistent within a "vendor".
I prefer to think of it as a "family" of cooperating modules, as it doesn't
have to be a single vendor, and doesn't have to be commercial.  It could even
be the case that one module provider could plop themselves on top of a module
provided by a different vendor by strategically choosing numbers.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module