Re: secmodel_{,de}register()

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Mon Apr 20 2009 at 04:23:45 +0300, Elad Efrat wrote:
> 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?

What are you trying to protect against?  bugs?  Sounds like quite a
radical bug.

Why not just register an unremovable allow-all secmodel and get rid
of special case nsecmodels==0 completely (or is it necessary for
bootstrapping)?