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

pollardat_private

"Titus D. Winters" <titusat_private>:
> > Titus D. Winters wrote:
> > >> > 2. Maintain current set of hooks and push logic out of the kernel and into
> > >> > the module to avoid placing hooks in compound conditionals.
> > >
> > >Yes, this is certainly an invasive solution, but not only is it the most
> > >general, it is the most elegant as well.
> >
> > Elegant?  Not from a software engineering point of view.
> > Almost every module will have a cut-and-pasted copy of the base
> > logic.  Software engineering teaches us that code duplication is
> > bad: If you ever want to change that code, making the appropriate
> > change in all necessary places is difficult.
> 
> Ah, but if we set it up so that the dummies/current logic are extendible,
> (say, with an EXTEND_CURRENT macro or something, I'm sure it's doable but
> have been unable to download the source yet to demonstrate), then there is
> no rewriting, the current code stays in the kernel and doesn't have to be
> looked at by module developers unless they want to override it.
> 
> Hmm . . . but yeah, actually now that I think about it more closely I
> suppose the problem would lay in the composition of modules and deciding
> again if your hook was going to extend and make more permissive or extend
> and make more restrictive.  Perhaps the extending the dummies macro coule
> be EXTEND_CURRENT_PERMISSIVE or EXTEND_CURRENT_RESTRICTIVE (again,
> assuming such a thing is easy to write and we choose an extention
> paradigm).
> 
> I'll still maintain my claim: more elegant.
> 
> > >> > 3. Maintain current set of hooks and keep logic in the kernel.  Add an
> > >> > argument to hooks to show whether the kernel was going allow or deny the
> > >> > action.
> > >
> > >I think, as a gut reaction, that this is going to make the hook checks in
> > >the base kernel a lot ugly and more incomprehensible.
> >
> > I don't think so.
> >   if (err = security_ops->hook(x, y, z))
> >      goto out;
> > becomes
> >   if (err = security_ops->hook(err, x, y, z))
> >      goto out;
> > I don't see why you consider the latter ugly and incomprehensible.
> > It's not elegant, but it doesn't seem ugly, either, and it seems pretty
> > easy to understand what it's doing.  What am I missing?
> 
> For example (out of sys_setpriority again)
> 
> no_nice = security_ops->task_ops->setnice(p, niceval);
> if (p->uid != current->euid &&
>     p->uid != current->uid && no_nice) {
> 	error = -EPERM;
> 	continue;
> }
> 
> would have to become
> 
> kern_logic = (p->uid != current->euid && p->uid != current->uid) ? 1 : 0;
> no_nice = security_ops->task_ops->setnice(p, niceval, kern_logic);
> if (no_nice) {
> 	error = -EPERM;
> 	continue;
> }
> 
> Which is, IMHO, noticably worse.

I would prefer:

no_nice = security_ops->task_ops->setnice(p, niceval);
if (no_nice) {
 	error = -EPERM;
	continue;
}

Or better:

if (security_ops->task_ops->setnice(p, niceval)) {
 	error = -EPERM;
	continue;
}

since the LSM would already have access to the process variables.

Either of these improves the kernel for the embeded Linux group, and
still preserves the current operation by having it in the LSM core.

Configuration of this should be something along the lines of:

Embedded Linux ?	-> no LSM required, and no security overhead

Basic Security ?	-> the base LSM with the current implementation
			   compiled into the kernel. (ie. not a loadable
			   module) It should still be available if embedded
			   Linux is chosen.

LSM module ?		-> base LSM as a module.
capabilities ?		-> base LSM + capability (might be loadable if previous
			   option taken)

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

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