Message-ID: <e7d8f83e0710241826q636bb5acwd268ec062eeb3370@mail.gmail.com>
Date:	Thu, 25 Oct 2007 11:26:07 +1000
From:	"Peter Dolding" <oiaohm@...il.com>
To:	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

I have different deal breakers.

If a LSM is something simple/commonly required it should be made like
posix file capability's provided to all to use.   Sorry to say I see
the file protection in apparmor as something everyone should be able
to use at will like posix file capability's.  All enforcement features
should be common.

I see a LSM as a director commander its reason for existence is to
read security configs and hand them permissions and respond to
problems.   Any enforcement should be default in kernel.

So LSM could be roll based, mac or any other model.  Current problem
enforcement and guiding are mixed up in one block.  So evolution is
not happening.

The enforcing bits of LSM's should be a simple no brainier addons to
the Linux kernel.  The problem is at moment they are mixed up with Mac
....  A security model to use has to be picked to suit job.   Role
Based can be Better than Mac and Mac can be better than Role based.
It all depends on what you are defending.

Thing common all need to protect suid, file access, network access...
The bits you need to defend don't change if or if not you are running
a LSM.  So why are these bits bottled up inside LSM forcing people to
choose the wrong security model for there task to get protection at
times.

There can never be one LSM to do every job.   But the big but all the
common bits to protect every job could be in kernel.  Only thing
missing is the director.

This is exactly the same problem Virtual Server solutions had when
then wanted to get into the kernel.   At least the Virtual Server
solutions were not as pig headed as some of the LSM guys about it.
Where its all in or not in at all.   Little bits into kernel is better
than nothing.

Really this will sound bad if I had my way I would kick all LSM's out
of the main kernel tree until they learn to work with each other to
share bits.  We don't need 10 copies of protect files from access.  Or
10 copies of limit what .so a application and interface with and so
on.

It worked with Virtual Servers to get them to sit down and start
talking.  What we really need working on is system wide security.  No
bothering a lot about the little box of LSM.

Yes I am not nice to LSM.   I see them as bitrot.  They are going to
cause containers problems in there current form as containers evolve.
They are not improving the base line security level.  Yes selinux
saying make me default to improve secuity says that in selinux there
are parts that should be chopped out and made default.  But since it
contains a security model it cannot be all made default because it
just will not fit everywhere.

Basically a LSM should make it simpler to run security tight.  The big
all mighty but it should not alter achievable security.  If its
altering achievable security main kernel is missing features and
someone needs to slice and dice that LSM.

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