On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
>
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.
What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.
In a wider contect than just this list, it apears to me that MLS and
Obj Caps advocates simply dismiss the alternative models as broken or as
irrelevant at best. In my view this attitude is very much pressent on
the MLS list.
It might in the light of this attitude even be a viable option to just
simply spin off 3 (or more) sets of LSM module sets, and maybe even put
some ifdefs in the base code depending on the chosen access controll model,
if for some reason the 'model' warants some major patch.
To me it would look like a good concept if LSM/Linux would try to support
all exisiting formal models of access controll, but without the need to
support all implementation alternatives for these models. That is, if a
module 'requires' a patch but the underlaying formal model does not, than
it would seem reasonable that the module be fixed. If however the 'model'
seems to require the patch, it may be perfectly reasonable for this patch
to be implemented, if need be with an ifdef for the used model.
Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to first
think about what formal model they are actualy using, thus resulting in
cleaner module design.
Rob
Rob Meijer wrote:
> What may be even more relevant are those concepts that couldn't be done
> in SELinux, and how proposals that come from the theory of alternative
> access controll models (like object capability modeling) are dismissed
> by the aparently largely MLS/MAC oriented people on the list.
Clearly what is needed here is for someone to actually implement an
object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor,
MultiADM, or TOMOYO can implement object capabilities, so there is clear
justification for building such a module. I would argue strongly to
include it.
> Thus IMHO it may be a good idea to instead of a maintainer for LSM
> modules as proposed, alternatively a maintainer for each formal model
> may be more appropriate. This also would require module builders to first
> think about what formal model they are actualy using, thus resulting in
> cleaner module design.
>
I *really* dislike this idea. It seems to set up the situation that the
only acceptable modules are those that follow some "formal" model. Problems:
* What qualifies as a formal model? This becomes an arbitrary litmus
test, depending on whether the model was originally published in a
sufficiently snooty forum.
* What if someone invents a new model that has not been "formalized"
yet? Should Linux be forced to wait until the idea has been
through the academic mill before we allow someone to try
implementing a module for the idea?
* The proposal only allows a single implementation of each formal
model. In theory, theory is just like practice, but in practice it
is not. SMACK and SELinux follow substantially similar formal
models (not exactly the same) so should we exclude one and keep
the other? No, of course not, because in practice they are very
different.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
On 10/29/07, Crispin Cowan <[email protected]> wrote:
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model. Problems:
>
> * What qualifies as a formal model? This becomes an arbitrary litmus
> test, depending on whether the model was originally published in a
> sufficiently snooty forum.
Agree slows development and experimentation with a idea BAD. I would
more say function and reach of model and how its ment to operate
documented clearly. So next coder along is not taken wild guess. It
must be so clearly documented that almost any system admin could
understand how much or how little protection it is providing.
> * What if someone invents a new model that has not been "formalized"
> yet? Should Linux be forced to wait until the idea has been
> through the academic mill before we allow someone to try
> implementing a module for the idea?
Experimental until documented out of tree following mine.
.
> * The proposal only allows a single implementation of each formal
> model. In theory, theory is just like practice, but in practice it
> is not. SMACK and SELinux follow substantially similar formal
> models (not exactly the same) so should we exclude one and keep
> the other? No, of course not, because in practice they are very
> different.
Drop a stick on both of them. Since they both operate substantially
similar they should be directly prepared to share code with each
other. If one is not prepared to work with the other openly and
fairly out the tree it goes.
It could quite simple become the only thing different between Smack
and Selinux in they way they read configuration files. Long term the
most user friendly and security solid modules win. So long term one
wins short term any number of models. We of course wait for that to
happen. Note it could be agreement between coders. Since they were
force to work as one if there is merit it will come out. There is no
room for empire builders. We need security builders. Part of that
is getting your code examined by the most number of people able.
Same with apparmor vs selinux both can provide file access filtering.
So why two sets of code to do it.
LSM need a really strong maintainer prepared to beat a few ears in.
Or all we will endup with is usable modules. Selinux pain in but to
configure no not really usable. Maybe flaws in Smack so force to use
Selinux. Apparmor too weak.
Basically a stack of trash is the current LSM model. LSM's are fast
turning into x86 vs x86-64 bitrot all over again accept this time 100
times worse. What is basically bitrot caused by not sharing.
Stackable modules maybe. More important shared source code to do
stuff and common standards between LSM used where able. This also
should make it simpler for new models to be added and experimented
with. Since the new model may not need to redo all there hooking
system all over again. Reduced security risk more tested code used in
new models.
Next more important extend security down into applications if
applications need it. File access filtering would be a great feature
at the thread level.
We have enough LSM's to be hard. It a privilege to be in the main
kernel tree not a right. Part of having a module in the Linux kernel
tree is a promise to do what is right for everyones security using the
kernel even if it means the end to your LSM's existence. Part of
doing what is right is sharing of code. All LSM developers should be
looking at there code and asking should this be like posix file caps
and for everyone. Or should this be a LSM only feature because its
useless to everyone else. From what I am seeing LSM maintainers don't
seam to think its part of the requirement to help other LSM's be
better even if theirs ends up losing. Only if you are building a
Empire does it matter who wins or loses the long term of LSM's. Only
thing that truly matter is that we get the best long term.
Peter Dolding