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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e7d8f83e0710252244y46744aaemca838f8431973ae8@mail.gmail.com>
Date:	Fri, 26 Oct 2007 15:44:17 +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)

Ok lets get to a good point.

Lets define a key bit.   What is a good software security lock?

My define is that its available to be used everywhere its needed and
when ever its need without flaw.

This is where most LSM fall in a heap.  Because you have to have the
LSM loaded to have its security features and cannot always be mixed
with other LSM it failes the when ever it is needed test.

On top of this most LSM features don't provide any form of direct
control to non admin users or applications to lower there access
rights.  So it also fails to be used everywhere its needed.

Since the LSM design itself is flawed in my eyes.   These flaws make
it hard for LSM to share tech advantages with each other.   LSM are
very much like putting a lock threw the front wheel of a bike.   So
the thief removes the front wheel and walks off with the rest of the
bike.  The critical data is in the user accounts.

The big thing with most LSM how do they handle security inside a
application on a thread by thread base.  They don't reason it gets too
compex without known the internals of the application.

We are talking security here and design of LSM's are not offering the
option max security.

Max security has to get down to a single thread inside a application
with all the security blocking features LSM's offer.  Reason a flaw in
that thread could be made completely harmless even that the other
threads in the application has complete system rights.

Idea of Max is to keep application flaws to as minor security flaw as
they could have been.   Ie Hopefully no risk because the flaw happened
in a section of code with no rights.

This is virtually imposable for any form of profiling creating
security to ever do(LSM profile based security).  What is needed is
application controlled security with profile based security as fail
back.  I know this means ripping your LSM parts apart and designing in
application controls.  Allowing features to be shared between LSM and
even to be there when the LSM that feature came from is not being
used.

First goal should not be to get a LSM static linked into kernel or
anything else bar getting the security system to a point that max
security is on the table if people want it.

I will say this again in my eyes LSM's should be thrown out of the
kernel completely because they are only offering fake max security.
Selinux and other LSM's on max is not even close to what should be
offered.

Basically Linux is a sitting duck for data thief third party  that
steal from the users home directory personal information.   And its
not like application developers are being given the tools to prevent
that.  Cost and loss does not start only when applications normal
profile of access is breached.   It starts way before that.

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/