You are all focusing on vendors.  I am thinking server farm or people
running many different distros side by side using containers.   Voided
support is only one factor.  If I have a application lets say only
runs on Redhat and another that only runs on Suse.   I am really not
going to give a stuff about vendor kernel since vendor kernel is not
going to give me anywhere near the same speed or numbers of machines I
can run.  Ie lguest kvm vs containers.  They loss every time to
containers.

When containers get operational in Linux kernel full time.  There is
nothing to say segments of servers will not be rented out.   Now if
you have a redhat and novell server images on the same kernel both
will need different combinations of LSM.  Or there security will not
work right.

This becomes particularly important to be able to apply LSM in a
controlled method if/when Linux allows containers of running servers
to be sent between servers.  Since there might be no longer any need
for apparmor or selinux or some other LSM to still be loaded on a
particular server.  Loadable LSM has to stay even if more security is
put around it.

With containers its likely that Linux distros might contain many
different LSM's in there kernel any how so they can load other Distros
under there kernel effectively.  Since the Distro to do this will most
likely get more server market share particularly if they will support
running other Distros under there kernel.

Sarbanes-Oxley is null and viod if the Distros end up providing it.
Since multi LSM's would be the standard kernel.   Do not bother about
laws like Sarbanes-Oxley the rules are flexible.  Do what is right
long term and Distros will follow.

Now the more important thing is looking at lifting the bottom level of
security so if the LSM is down or disabled server/desktop does not
straight up come a sitting duck.

I have stated bits and pieces of what is required before.

As I said before the complete line is pointless you are talking about
hear and now.   Not the future.   Security alterations need to be
planed for future needs as well not just current day requirements.
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to