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

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.

-Titus

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