Message-ID: <e7d8f83e0710311904w45827586oabcca597fd612ea6@mail.gmail.com>
Date:	Thu, 1 Nov 2007 12:04:23 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	"Toshiharu Harada" <haradats@...il.com>
Cc:	"Crispin Cowan" <crispin@...spincowan.com>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

The Clear and Important thing is there is already a single security framework.

The single security framework is the security that exists when no LSM
is loaded.  It turns out the more I look most of my model already
exists just not being used effectively.  There is a capabilities frame
work at worse needs expanding to handling more detailed controls.
Like X thread can only read x y z files an write to a file.

Improvements to the single security framework are getting over looked.
  I would have personally though selinux would have done Posix file
capabilities as a general service to all.  But no IBM had to do it.
This shows a problem.  Critical upgrades to the single security
framework are not being made by LSM producers.  This means one thing
LSM producers are putting there framework before the good of everyone.
  This just cannot keep on going its a path to more and more forks and
more confusion.

Is it Linus getting in way I think not.   Because upgrades are making
it.  Slowly making it but they are making it.   Is it LSM makers
trying to alter the single security framework to there model.  I am
almost perfectly sure that is the main problem.  Next problem is LSM
vs LSM one up man ship ie mine is better than yours or Mine can do all
yours can with 12 times more complex config file.  Not taken a
complete look to see if both sides have advantages.

Part the problem is if you upgrade the single security framework
enough selinux apparmor... most of the LSM will become side shows of
very little importance to security more a s backup to the main
security.  Focus may move back to the old unix locations.  PAM for
creating users and assigning rights and application controlled
security.

Key thing to put  features into the existing single security framework
is flexibility and application control.  Application controlled
security can always beat selinux apparmor and every other LSM I have
ever seen.  The most advanced design of security just happens to the
one you cannot remove.   It also happens to be the most neglected.
The weaknesses that exist in the single security framework is lack of
advancement and repair.

What I class as features is like a fix to a small part.  Ie SUID too
powerful fine grained controls required.
Disk access control methods for file systems without using the
permission system. << Apparmor and relegated path base back end
engine. This also partly allows applications to protect there own
internal users from each other without needing to create system wide
users.  Basically in time internal application users should be equally
protected from each other as system wide users.  This enhancement goes
far past the common day scope of apparmor.  This is the advantage of
taking it out of LSM or at least looking to.  You may see where it can
be make 1000 times more useful as feature than a LSM and provide many
more times system protection even in ways a LSM never could.  Yes
altered apparmor could be really sell able as a core feature.

There are a lot of parts in LSMs that can be broken down into single
feature enhancements.  Major difference is how these features are
controlled.   Applications must be able to directly lower access on a
thread by thread base.  Never raise it.  These features are also
provided to all users on the system to control always even if they
cannot use them due to lack of rights.

Explain to me how its not bitrot leaving the key security framework
without features and then dividing up those features between different
incompatible parts.  This is the basic define of bitrot because you
are making a bigger and bigger mess.

Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists