Re: Assurance, permissiveness, and restriction

titusat_private

> > 1. Political difficulties should not be considered in the design of
> > software.  Anyone that says otherwise is trying to avoid a flamewar.
> > Personally, I'd rather fight the flamewar battle personally and let
> > someone else do the development if that's what it takes to get it done
> > right the first time.
>
> I don't understand this argument.  I don't mind flamewars, but LSM
> is worthless to us if it is not accepted into the Linux kernel.  So
> we have to consider how acceptable our solution will be to the Linux
> kernel developers.

But if something substandard that is going to have to be extended again is
accepted into the kernel we haven't helped that much either.  This is open
source we are talking about, not pushing something insane past managment.
If we can demonstrate that there is a need for this (and anyone that
_can't_ demonstrate a need for security needs to watch the news from time
to time), and show that it isn't harmful, it should not be impossible to
accomplish.  If it just takes a knockdown drag out flamewar on the main
kernel dev list, then that's what it takes, but we need to put out the
best version of this that we can.  Planning on making n versions of
this so that we can get it through is just a waste of time, both ours and
the main developers.  Lets push to get done what we know now needs to be
done, and then we can _be_ done.

> Where's the real argument for moving all of the base logic out of
> the kernel?  Identify exactly what project needs it, and why it
> can't be supported adequately through separate hooks (including
> the capable hook for permissive behavior).

Robustness - anything you can code can be implemented as a security
mechanism, even parity of your system clock if that's what you want.

Cleanliness - all the security logic is in one place, easy to find, easy
to work with.  Furthermore, we aren't adding in the intuitional complexity
of storing what the kernel thinks should be done passing it in to the
module, and then reacting to that.

Simplicity - This way we don't need to double up hooks (hook_permissive,
hook_restrictive, etc).

I don't think we need to be thinking about the modules that are
specifically being developed now, we were chartered to develop a framework
that could be worked with that didn't enforce any policy.  This is the
most applicable approach to that to date.

> I can't see us devoting resources to such a significant effort when
> it doesn't provide any benefits for our security modules and it
> doesn't help our case to the Linux kernel developers.

It is no more significant than anything else we are doing, the way I see
it.  If it's the amount of coding effort that's the worry, I'll take care
of it myself.

The bulk of the complaints that we've been getting are political in the
worry that the kernel developers might not like it that we are messing
with stuff so deep.  I think we need to worry about the technical
obstacles (developing the durned thing) more than let our theoretical
concerns about political issues govern our contribution.

-Titus

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