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

jmjonesat_private

On Tue, 5 Jun 2001, Stephen Smalley wrote:

> 
> 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.  

I'm trying hard to envision this.  So leave ALL the logic untouched in the
kernel and move ALL of the capability stuff to the module behind
a unique set of hooks, in essence, reverting the places where previously 
we'd "mixed"?

Reverting to:

if (p->uid != current->euid &&
    p->uid != current->uid && !capable(CAP_SYS_NICE))

From the current

no_nice = security_ops->task_ops->setnice(p, niceval);
if (p->uid != current->euid &&
    p->uid != current->uid && no_nice) {
    error = -EPERM;
    continue;

Around line 217 in sys.c, for example, but moving the whole
no_nice thing to the MODULE side of the equation and cleanly intercepting
the "capable" call instead?

If I've got it right (which would be semi-miraculous), this would 
seem to simplify the logic and concentrate things into one place 
that previously were "fragmented" into different areas.

On first blush, if I have it right, I can't say I don't like it. :)
It moves the LSM calls into an LSM, leaving more of the kernel alone,
but doesn't hobble the LSM's ability to be more permissive or restrictive 
with regard SPECIFICALLY to capabilities. (I think.)  Is that generally
correct?

> 
> 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.
> 

Yes, it certainly seems to do all those things.

> 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.  

In essence, other than the capable() hook, we're reduced to
restrictive-only in where the logic is inserted in the kernel
UNLESS ... um... what?  I'm not understanding "easily", I guess. 
Does this move some logic to the module, with a flag that informs 
the module if the logic in the kernel may have allowed a 
"permissive response" (a la "option #2"), or leave the logic in 
the kernel and supply the "kernel's decision" to the module a la 
"option #3"?  I'm guessing the latter, but I'm foggy here.

> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalleyat_private
> 

Some of option #1, Some of option #3?

Please Forgive My Asking Possibly "Stupid" Questions,
Trying to evaluate in "hard" terms where this solution leaves me,
J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

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