Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-kernel@...>, <linux-security-module@...>
Date: Tuesday, October 30, 2007 - 10:21 pm

On 10/31/07, david@lang.hm <david@lang.hm> wrote:

I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?

There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
 Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.

That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.

We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.

System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.

This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not all Security features should be done in them.  Some
should be done in the main OS security features.

Biggest current day problem with LSM is they have forgot that LSM is
only a testing ground or a zone for features that people will only
want some of the time.

MultiAdmin is a feature that can enhance means to Audit OS ie who did
what.  Enhance security hand outs and can be really handy with almost
any LSM on the system.  Its description of what it is sounds very much
like every other standard feature.

Lets end the bitrot.  Start having bits go into the main OS security
features where they should be.

Peter Dolding
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: Linux Security *Module* Framework (Was: LSM conversion t..., Peter Dolding, (Tue Oct 30, 10:21 pm)
Re: Defense in depth: LSM *modules*, not a static interface, Casey Schaufler, (Tue Nov 6, 11:35 pm)
Re: Defense in depth: LSM *modules*, not a static interface, Casey Schaufler, (Wed Nov 7, 12:34 am)
Re: Defense in depth: LSM *modules*, not a static interface, Casey Schaufler, (Tue Oct 30, 11:01 am)