I have an LSM that I want to use with SELinux and capabilities.
One integral component of the LSM is that it uses audit functionality
to get information to user space both to refine the security specification
and, in the future, to facilitate identification of spy ware.
So I have some design questions which I suspect have been previously
discussed but in a couple of hours of hunting (admittedly mostly 2005)
I didn't find the relevant e-mails in the archives.
1) Is stacker intended mostly for experimental systems or for
production systems also? I have the impression that there are
concerns in this area.
2) Because Auditing is an integral part of my LSM it is important
that the methods be called even if another module is going to
deny permission --- this is not the semantics of
RETURN_ERROR_IF_ANY_ERROR. It appears that SELinux also
might have a similar concern.
Come to think of it, an LSM might want to modify its data
structures also.
3) For production systems:
a) Why is dynamically unloading (not just disabling)
a module attractive? The dynamic upgrade argument may be
valid here, but non trivial upgrades would leave me queasy.
Are there other reasons?
b) How many modules are anticipated in any single kernel?
I would have thought 10 a large number.
4) What are the circumstances where an LSM would need to
modify something other than its own data structures?
In other words, what is the argument for not insisting
that security methods are side-effect free except for there
own data structures?
Note that 2 & 4 together lead to a different design.
I fear that these questions cover old ground --- but I will be
willing to format the answers in a form to append to
Documentation/LSM-stacking.txt.
George Beshers, PhD.
This archive was generated by hypermail 2.1.3 : Mon Jul 11 2005 - 06:50:32 PDT