Cc: Stephen Smalley <sds@...>, Kyle Moffett <mrmacman_g4@...>, Linus Torvalds <torvalds@...>, Bill Davidsen <davidsen@...>, James Morris <jmorris@...>, Andrew Morton <akpm@...>, <linux-security-module@...>, <linux-kernel@...>, Serge E. Hallyn <serge@...>
Agreed. I wasn't thinking 1000 individual checks but 1000 different
capabilities, could be either checks or actions, basically fundamental
different capabilities. Things like CIPSO, or the ability to store a
security label on a file. I would not expect most security policies
to use most of them. Neither do I expect Orange book security to
necessarily be what people want to achieve with the LSM. But I
haven't looked at it enough detail to know how things should be
factored, in this case I was simply extrapolating from the iptables
experience where we do have a very large number of options.
The real point being is that I would be surprised if we could come
to an agreement of a common user space API when we can't agree on how
to compile all of the security modules into the kernel and have them
play nice with each other.
Assuming we can achieve security modules playing nice with each other
using a mechanism similar to iptables, then what needs to be evaluated
is the specific table configuration we are using on the system, not
the full general set of possibilities. Further I expect that for the
truly security paranoid we want the option to disable further table
changes after the tables have been configured.
On another side personally I don't see where the idea comes from that
you can describe system behavior as a whole without analyzing the
entire kernel. Has there been work on a sparse like tool that I'm
not aware of to ensure the we always perform the appropriate security
checks on the user/kernel interface boundary?
Eric
-
