Re: Possible system call interface for LSM

crispinat_private

David Wagner wrote:

> Crispin Cowan  wrote:
> >David Wagner wrote:
> >> Are there race conditions here?  What if someone does a
> >> 'rmmod selinux; insmod subdomain' between the time when
> >> you check for the presence of SELinux and use the syscall?
> >
> >Isn't that isomorphic to the problem of "what if the bad guy got control
> >of the machine before my module loaded?"  To me, anyone who can do
> >"rmmod" is either a trusted administrator, or has already broken
> >security so hopelessly that it's not worth arguing about.
>
> No, it's the difference between malicious attacks by untrusted entities
> ("bad guy got control") and accidential failures by trusted,
> well-intentioned entities (admin rmmod'ed, and some app just happened to
> be a syscall at the same time).

Ok.  So the LSM syscall and the LSM rmmod need an interlock.  For that
matter, ALL syscalls that LSM is going to hook need an interlock with
LSM rmmod.  I see approximately three ways to achieve this:

  1. Big boring locks.  Just use a classical lock that must be acquired by
     either hooked syscalls or rmmod/insmod.  Big perofrmance impact :-(
  2. Asymetric locks.  We (OGI) did a paper on this some years ago, which
     showed algorithms and implementations (which we subsequently ported to
     Linux) that allow a "fast path" (syscalls) and a "slow path"
     (rmmod/insmod) for synchronization.  Basically, you can't rmmod/insmod
     while someone is in the module.  Entry into the module acquires an
     asymetric lock that is cheap to acquire in the (common) case where it's
     available.  The cute hack is to use a function pointer as the lock.
     Paper here  ftp://cse.ogi.edu/pub/dsrg/synthetix/iccds96.ps.gz and code
     burried somewhere if someone really wants it.  Modest performance
     impact.
  3. Human locks.  As David suggested, just put it in the docs that you
     can't rmmod/insmod a system without quiescing LSM-related activity.
     David seemed to view this as a negative point, but I don't see the
     problem. No performance impact :-) modest administrative impact :-/

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