On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses who are not prepaid to share.
Here as always all three should see where they can share code and get
the best performance this might mean AppArmor and Tomoyo use Selinux
labels because it causes less overhead. Or Selinux provides a
optional path based using the other engine. Both are providing the
same feature in different ways. Question does have to be asked is
there bench testable justification for need two for file systems
filters.
Both of these are sharing backwards and forwards between each other so
being nice with each other. LSM overall Maintainer only really need
to at worst way xyz sections are not merged/shared and to document why
with benchmarks if they are not going to be. Ie tested reason.
Both is a valid answer. Sections done path based should be shared
with other path based and labal based shared with other label based.
Ok section by section where would it be best for that code base to share with.
MultiADMIN falls under o my god head ache. This is more a posix
standard feature altered ie 1 root user turned into many. This really
risks breaking the other models as a LSM. Its more of a all in or all
out. Really it needs to be lowered out of LSM into a standard
optional Linux feature so it cannot breach the security of other LSM
modules. Also LSM modules will need to be made able to tell a
MultiADMIN root users. This is part of what I was talking about some
parts need to be as lower down module not at full blown LSM level.
This is the rare one where the complete model needs to be moved down.
There are bits in almost all LSM that need to be looked at being made
full time features of linux like quotas and posix file capability's .
Dazuko is the rare user mode controlled interface. Still same rule
share code where able. Anti-Virus integration and other protecting
systems are commonly overlooked by LSM's. Same here if this should
be a LSM or a kernel optional feature independent to LSM that a LSM
can block from happening.
You will hate me but I don't call that formal enough. Its lacks the
critical bit of doc written in terms that any system admin can
understand what they are being given.
Next question should RaceGuard be a LSM at all. Or should it be a
standard feature what LSM can over rule? <Swap RaceGuard out standard
question for all new LSM's and LSM features>
Lot of things are being pushed as LSM's when they should be pushed as
expanded default features outside LSM.
Peter Dolding
-
