[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: secmodel_register(9) API
On 29.11.2011 14:25, Matthew Mondor wrote:
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
That can be done.
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
For keylock secmodel (which does not use the module framework), panicing
would be better, definitely.
For the other modules, that depends on the functions; usually,
_init/start initialize and register listeners, but an error can be
returned and will be handled by module framework (like we do with
secmodel_register() for suser and securelevel).
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
I don't follow you there: what do you mean? replacing strings with
ad-hoc integers? Secmodel documentation to explain how these commands
should be interpreted? Something else?
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.
Hmmm, the "dynamic" part here is too allow querying for state (and even
setting, if there's a need to), without putting any requirement on the
presence of a secmodel.
Usually, higher level languages come with a runtime that allows to query
for module/instance states safely, and handle exceptions that could
occur when the element is absent or invalid.
In C alone, we can't. You have to find a solution around this
limitation, and this is the sole purpose of this API: query a secmodel
and allow the API to return an error when the secmodel cannot handle the
request, because it's either not loaded or non existent.
We could also design the API to use the in-kernel linker to access
secmodel variables, but this had two downsides:
- you have to expose a symbol for the thing to be resolved
- you cannot implement complex logic, where you need argument evaluation
by the targetted secmodel (suser "is-root" is a good example).
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.
Make them into builtin modules. You won't be able to unload them any
more, and the secmodel_eval(9) is still there to send requests between
Security people usually turn off a number of dynamic options in a
kernel, from modules loading/unloading, BPF filters, uneeded drivers and
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
FLASK/Fluke? Now, if you like complexity...
But then again, I'm only pipe dreaming, and that's always easier than
implementing any of that, of course :)
Beware of dreams that can turn into nightmares :)
Main Index |
Thread Index |