secmodel_{,de}register()

[Elad Efrat <elad%NetBSD.org@localhost>]

Hi,

I'm a little bit concerned that secmodel_deregister() just lowers the
number of secmodels registered without asking for too much. Obviously
this isn't a problem yet, but I'm trying to think if we are letting
newly introduced kernel code (say, a module) simply neutralize kauth(9)
for the entire system.

Since a kauth(9) listener does not have to be part of a secmodel, we
can't really rely on the answers we're getting from listeners if at all
to decide whether we *really* don't have a secmodel or nsecmodels was
just lowered by repeated calls to secmodel_deregister() (that's possible
on non-DIAGNOSTIC kernels).

One thing I thought about was to add some sort of "key" that would be
generated and returned by secmodel_register(). This key is to be used
when calling secmodel_deregister(), to make sure the caller did register
a secmodel.

Of course, this solves potential API abuse only.

Given the fact that we're talking about kernel code, and that we
don't yet have a solution for protecting from simply accessing the
nsecmodels variable (or the list of keys if we decide to solve it
using the above), do we still want to prevent the possible API abuse?

Thanks,

-e.