Re: A Comment from User Space

crispinat_private

jmjonesat_private wrote:

> I like the idea of being able to load modules into Linux that
> will overlay the current security model and protect kernel objects
> from tampering and grant much finer permissions/privileges to
> specific processes, but would like to voice the following concerns
> from the "guys who are gonna have to use this system" end:

On most of the points below, you have *precisely* captured the design
goals of this project.

> 1) OVERHEAD OVERHEAD OVERHEAD.  One of the great things about
>    Linux is you can still get good performance out of a MIPS
>    Nevada 1.0 or Intel Pentium I 133.  1% may seem reasonable,
>    with Moore's Law working and all, but it can be a real make
>    or break.  Please shoot for something more economical than
>    that, or consider ways to optimize the kernel to "enhance
>    away" the performance hit.

I totally agree.  WireX's security products tend to impose at most 1%
overhead while enforcing various security policies, so it is my hope
that the LSM interface infrastructure imposes considerably less overhead
than that.

> 2) SIZE.  The Kernel is already much too large and heavy for
>    my taste, although I love every little tweak that's been
>    added.  Could some of the EXISTING internal functions be
>    moved to a "default module" which would be replaced by
>    an enhanced security module, thereby recovering some of
>    the cost in resource?

Exactly.  The first LSM module being built is an implementation of the
POSIX.1e Capabilities code.  This means that it can come out of the
kernel.

> 3) TRANSPARENCY.  I spend a lot of time testing and hardening
>    and kludging security systems at the application level.
>    While it is arguable that providing access to capabilities/
>    permissions/privileges to userspace programs could introduce
>    more overhead and, possibly, vulnerability,  I can actually
>    envision an "aware" program polling for it's permissions and
>    abandoning some of it's OWN internal security checking because
>    it is being provided by an underlying layer, resulting in a
>    recovery of some overhead.
>
>    If a "general purpose interface" can be devised that would
>    provide meaningful information to userspace programs about
>    their environment, regardless of the specific module, it
>    would be useful "out here in the common lands."

Here you kind of lose me.  A properly functioning program should not do
stuff that violates the security policies.  Normal applications can and
should be fairly oblivious to the security policies in place, and
shouldn't really need to ask questions about security policy.

Applications that do want to learn this kind of thing normally use the
access() system call, and that call should continue to function.  A
module that restricts program behavior but fails to report those
restrictions through the access() system call can be referred to as
"broken" :-)

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module