Re: permissive vs. restrictive issue and solutions...

sdsat_private

On Mon, 4 Jun 2001, Crispin Cowan wrote:

> That's interesting.  "kick capabilities out" was popular with WireX engineering at
> last week's weekly meeting, and with David Wagner.  The remaining request for
> permissive controls is Casey's, but he hasn't said much about it.

Just to be clear, I'm not really suggesting that we "kick capabilities
out".  Here is what I am proposing:

1) We leave the existing capabilities module alone, but we revert the
calls to capable() in the kernel.  The capable() function remains
as a stub that calls the LSM capable() hook (or, better, we
use a script to globally replace all calls to capable() with a
direct call to the hook).  We also replace the capabilities system calls
with stubs that call LSM hooks, and move their functionality into the
capabilities module.  

This supports the following desireable goals:
a) People who don't like capabilities can easily use a superuser
module in place of the capabilities module.
b) The capabilities developers can easily evolve the implementation
of their core logic without involving the kernel developers.  In
particular, they should be able to provide their new logic with
real file system capabilities as a module (assuming they can get
the corresponding file system support adopted in some way).
c) Both the superuser module and the capabilities module only
need to implement the capable hook and the hooks related to
execve processing and the capabilities system calls.  All
other hooks can simply return 0.
d) Other module developers can support DAC overrides using methods 
other than superuser or capabilities (e.g. Type Enforcement) by
implementing their own capable() hooks.
e) Kernel code modifications related to capabilities are minimized 
and localized.

2) All LSM hooks other than capable() should be used authoritatively.
If a LSM hook can be easily placed at the same location as the
existing logic, then the LSM hook can take an additional parameter
to give it the option to override the kernel's logic, in which case
it can be used either restrictively or permissively.  If not,
then LSM hook can only be used restrictively.  

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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