Re: Security through Permissiveness: A Zen Riddle?

crispinat_private

As I understand Shane's original request, it is to get away from the
UNIX all-or-nothing "root" security model, without totally throwing away
UNIX.  Seth is correct that pure capability-based OS's like KeyOS and
EROS don't have this problem, but that is not the only way to solve this
problem.

Staying within the UNIX model, there are fundamentally two ways to skin this
cat:

   * Permisiveness: Find some way to grant special privileges to non-root
     processes.  This is the approach taken by the mis-named Capabilities
     POSIX.1e facility:  non-root processes can be granted sub-sets of root's
     powers.
   * Restrictiveness: Find some way to restrict the full power of root's
     processes.  This is the approach taken by chroot, SubDomain, LIDS,
     Janus,and (IIRC) SELinux.

The "permissive/restrictive" debate was about whether LSM should support the
permissive model.  This question is remarkably subtle.

Saltzer & Schroeder 1974
http://web.mit.edu/Saltzer/www/publications/protection/index.html codifies the
"default fail safe" principle:  by default, an access control system should
always deny access, and only grant access after due consideration.  At first
glance, this would argue strongly for the permissive model.

However, supporting a permissive model means that the LSM hooks enable a
module to grant arbitrary accesses.  If someone provides a broken module, it
can make security on the platform much worse.  If we apply the default fail
safe principle to the kernel itself, then the kernel should permit only
restrictive modules.

The compromise position is that Linux already supports POSIX.1e capabilities,
which provides a permissive security model.  Since that code is fairly old &
stable, we believe it can be maintained without substantial additional risk.
For all other LSM hooks, we prefer to stay with the restrictive model, so that
one can relatively easily be assured that LSM modules are not making things
worse.

So Shane should be able to achieve his goals through any one of several
different paths:

   * use POSIX capabilities to grant the particular privs desired to some
     non-root daemons
   * use your favorite restrictive module (SubDomain, LIDS, Janus, SELinux,
     etc.) to restrict some root daemon to only the activities it needs to do
     its job

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