On Tue, 29 Nov 2011 02:51:38 +0100 Jean-Yves Migeon <[email protected]> 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
