Re: secmodel_register(9) API

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 29 Nov 2011 02:51:38 +0100
Jean-Yves Migeon <jym%NetBSD.org@localhost> wrote:

> Reviews before merge welcome. If nobody raises his voice, I'll proceed 
> to commit it at the end of the week.

Hello,

I admit not having audited the kauth and secmodel code recently, the
last time being shortly after Elad's initial implementation, please
bear with me if some observations are irrelevant:

  There are various ad-hoc calls to printf() which could probably be
  replaced by a more generic function call also resolving the error
  number to a string matching the constant i.e. secmodel_perr(int
  errno, const char *function); or similar, possibly wrapped by a macro
  using __FUNCTION__ avoiding the redundant function names

  The initialization functions, such as secmodel_keylock_init(), will
  report an error in the dmesg but do not propagate errors (they're
  void functions, suggesting the caller will not suspect anything).
  Should not the system panic for similar security critical failures?
  I think that I saw a similar situation under the various "case
  MODULE_CMD_INIT".

  When seeing the strcasecmp() calls in the eval_* functions for names
  such as "is-securelevel-above" or "is-root", my first impression was
  that integer constants, macros, or even a system of interned strings
  and references would be nice.  Then it struck me that if the goal
  was to export these, exporting actual variables might be best
  (although in any case, exporting these seem to somewhat defeat
  kauth-style centralization.  But if I understand, this is not for
  general use in the kernel, but for use by other security models?  If
  so, it's not so much out of scope in the sense that it remains in
  sys/secmodel)...


Note that the following is not criticism on your patch, but
pipe-dreaming and opinion.  It's also outside the scope of the existing
kauth implementation, but I couldn't resist, considering it was slightly
on-topic:

Having a main area to look for security related decisions is a good
thing, and kauth was a good step in that direction.  It's also nice to
permit an administrator or organization to tweak the system for their
needs using an elegant architecture.

However, I've always found its design to be slightly too dynamic,
perhaps too much of an interpreter (and those eval_* functions make it
even more so).  Then there is all the C code dedicated to attaching,
detaching parts to the "program tree" at runtime, etc.  Although I'm
not familiar enough with the original Darwin implementation, that is
probably similar there.

Since this is security related, it would not be unreasonable if the only
possible runtime changes were user/admin configuration (module-specific
sysctl configuration knobs, file system permissions, PaX flags, etc).
This means that the final runtime security system could be statically
generated at compile-time.

Dreaming ahead along that path (this part could still be possible with
an interpreter-like model though), it might be possible to create a
similar system, centralized yet modular (not at runtime, but for
human-friendly organization), to design and use a simple mostly
declarative language to edit and represent security models, then
compile that representation to static code.  The input could be more
elegant (also more easily allowing to define the domains and their
authorize interface, any hierarchies, etc), the output could permit a
more efficient runtime (generating unrolled code where wanted rather
than loops running among hooks lists)...  And of course there could be
specialized static analysis and test tools to warn model designers of
possible shortcommings in their designs.  With finally a preprocessor
tool so that it'd be possible to embed the language with C code, where
necessary...

But then again, I'm only pipe dreaming, and that's always easier than
implementing any of that, of course :)
-- 
Matt